I’ve been trying to obtain either IMPORTED_LOCATION_DEBUG, IMPORTED_LOCATION_RELEASE, IMPORTED_LOCATION_RELWITHDEBINFO, or IMPORTED_LOCATION_MINSIZEREL for a target, depending upon the configuration that I’m currently building, and then strip off the filename to get the directory.
For a single-configuration generator, this works fine:
Generator expressions are evaluated during generation step so they cannot used directly in CMake commands except when they are evaluated as part of some commands like file(GENERATE...) for example.
However you can simplify your command using the following syntax:
if (CMAKE_BUILD_TYPE)
get_target_property(PY_LIB_ADDRESS python IMPORTED_LOCATION_${CMAKE_BUILD_TYPE})
else()
get_target_property(PY_LIB_ADDRESS python IMPORTED_LOCATION)
endif()
And to finish, as far as I know, get_filename_component() does not support generator expressions.
PY_LIB_ADDRESS = PY_LIB_ADDRESS-NOTFOUND
CMake Error at <file & line no.> (set_target_properties):
set_target_properties called with incorrect number of arguments.
…which is what I’d half-expected, because CMAKE_BUILD_TYPE is a mixed-case string whilst I thought the suffix to IMPORTED_LOCATION needed to be upper-case.
get_filename_component() definitely works with generator expressions. I’ve used this form elsewhere:
But your interpretation of behavior of get_filename_component() is erroneous. If you look at PDB_PATH contents, you will see that generator expressions are not evaluated. The evaluation occurred during generation when property COMPILE_PDB_OUTPUT_DIRECTORY is evaluated.
Again, I repeat, generator expressions cannot be used during configuration step because they are evaluated during generation step.
…so the unqualified ‘IMPORTED_LOCATION’ property is never defined explicitly. Will the format you suggest still work in that case, with a multi-config generator?