In most ExternalProject_Add calls we are currently using just CMAKE_ARGS. Additional possibilities of passing variables are CMAKE_CACHE_ARGS and CMAKE_CACHE_DEFAULT_ARGS. CMAKE_ARGS do not support semicolons as list separators which currently leads to loss of list entries in some cases, where semicolons are not replaced by another list separator like ^^. However, we do not have full control over external projects regarding handling of special list separators. A clean and easy solution is to pass lists as (default) cache args if appropriate, e.g., which is true in case of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, and CMAKE_LIBRARY_PATH.
Description
Description
Event Timeline
Comment Actions
[10559e]: Merge branch 'bug-18875-EpCommonCacheArgs'
Merged commits:
2015-03-20 03:35:46 Stefan Kislinskiy [0a214f]
Introduced ep_common_cache_args and ep_common_cache_default_args.
Comment Actions
Can you elaborate on the "we do not have full control over external projects ... list separators" ? AFAIK, the ExternalProject_Add command handles the replacement of the special list separator (e.g. "^^") into ";" before actually setting the list variable for the external project.
Comment Actions
You're right, the replacement happens when the command line is made up by ExternalProject_Add. However, I remember that we have (or had?) cases where we transitively pass the ^^ separator to external projects. A more prominent example is/was MITK itself used by MITK-MBI regarding Boost libraries. I didn't check if we still do it this way but at least code for replacing ^^ is still present.
We also had loss of paths from lists when calling CTest functions, where we only have the possibility to work with the command line. These are cases were ^^ would be passed to the tested projects. Here, using the -C command line option for specifying a defaulted initial cache was the solution to allow passing lists separated by semicolons.
Anyways, the true benefit here is to get rid of error prone special handling of list separators which currently showed up again on CMAKE_PREFIX_PATH, which was a mixture of ; and ^^ separators, depending on how the variable was modified (manually concatenated in a string with ^^ or by using list(APPEND)). We also have some lines of code where ^^ is replaced by ; and vice versa. We should check if the affected variables would be fine to be passed through the cache as well to get rid of the replacements.