Laurentiu Nicolae wrote:
My project requires the generation of DLLs and executables with
different postfixes for different configurations. Therefore I am setting
the <config_OUTPUT_NAME accordingly. However, when I try to add a
post-build step to the build (as described in the manual), the LOCATION
property of the target is set to the original generated name, regardless
of the configuration. I can of course work around this by setting the
prefixes by hand in the post-build command, but I believe this to be a
bug. The reason being: if I am using the <config>_OUTPUT_NAME options,
the LOCATION property becomes rather useless, because it points to
something that may not be there any more.
Yes, this is a bug. The LOCATION property was around long before the
target properties that could affect the name on a per-configuration
basis. When those options were added the LOCATION property was never
updated to deal with them and was left alone to support existing code.
CMakeLists.txt excerpt:
SET_TARGET_PROPERTIES ( ${ProjectName} PROPERTIES DEBUG_OUTPUT_NAME
"${ProjectName}D" )
SET_TARGET_PROPERTIES ( ${ProjectName} PROPERTIES
RELWITHDEBINFO_OUTPUT_NAME "${ProjectName}Q" )
SET_TARGET_PROPERTIES ( ${ProjectName} PROPERTIES
RELEASE_OUTPUT_NAME "${ProjectName}R" )
GET_TARGET_PROPERTY ( DllLocation "${ProjectName}" LOCATION )
ADD_CUSTOM_COMMAND ( TARGET "${ProjectName}"
POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -E copy "${DllLocation}" "${QOutputPath}"
)
This is a known problem we've been ignoring until someone needed it
because it is a pain to address. The problem is that we need to have a
single value at CMake configure time (the LOCATION) split into multiple
values at CMake generate time (the per-configuration LOCATION).
One idea we've had is to return a special string for the LOCATION
property which is recognized by the generator and replaced with the
right thing in each generated configuration, though this leads to a
hackish special syntax behind the scenes. Another idea is to allow a
separate custom command to be specified for each configuration, though
this will lead to duplicate code and complicated loops in user code. We
have not figured out quite what to do.
Please submit a bug report here:
http://www.cmake.org/Bug
Thanks,
-Brad
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
