Reputation: 6391
The use case for the following problem is macro packages which are deployed, so the input is entirely user defined.
Consider the following minimal example:
function(foo)
cmake_parse_arguments(FOO "" "POSSIBLY_RELATIVE_POSSIBLY_GENEX_PATH" "" ${ARGN})
# Chosen as an example for a necessary step which doesn't have a generator expression equivalent
get_filename_component(
ABSOLUTE_PATH
"${FOO_POSSIBLY_RELATIVE_POSSIBLY_GENEX_PATH}"
REALPATH
BASE_DIR
"${CMAKE_CURRENT_SOURCE_DIR}"
)
# Compatible with generator expressions by itself
add_custom_command(
OUTPUT
${MY_OUTPUT}
COMMAND
${MY_TOOL}
${ABSOLUTE_PATH}
)
endfunction()
add_custom_command
itself supports generator expressions, but the need to go via get_filename_component
to handle one class of input (relative paths, for brevity in calling code), and the use of that intermediate step being impossible for the other class of input (build type dependent generator expressions, which get scrambled by get_filename_component
) clashes.
get_filename_component
effectively can't be used whenever POSSIBLY_RELATIVE_POSSIBLY_GENEX_PATH
had contained any genex components. get_filename_component
has no generator expression equivalent either, so substitution of that logic isn't possible.
Is there a robust way to detect the presence of valid generator expressions in a CMake variable, so it can be used as a signal not to attempt any non-genex transformations on that input?
Upvotes: 2
Views: 739
Reputation: 66278
You could use command string(GENEX_STRIP) which strips generator expressions from the string, and compare its result with original string:
string(GENEX_STRIP "${FOO_POSSIBLY_RELATIVE_POSSIBLY_GENEX_PATH}" no_genex)
if(FOO_POSSIBLY_RELATIVE_POSSIBLY_GENEX_PATH STREQUAL no_genex)
# The string doesn't contain generator expressions.
# It is safe to use e.g. 'get_filename_component'
else()
# The string contains generator expressions.
# This case requires special handling.
endif()
Upvotes: 6