MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003250CMakeCMakepublic2006-05-17 03:352012-09-03 16:00
ReporterLaurentiu Nicolae 
Assigned ToBrad King 
PrioritylowSeveritymajorReproducibilityalways
StatusclosedResolutionnot fixable 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003250: <config>_OUTPUT_NAME not used as target property LOCATION
DescriptionMy 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.

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" )

----------------

Comments from Brad King:

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.

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.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-03-09 14:39Brad KingNote Added: 0028882
2012-03-09 14:39Brad KingStatusassigned => resolved
2012-03-09 14:39Brad KingResolutionopen => not fixable
2012-09-03 16:00David ColeNote Added: 0030831
2012-09-03 16:00David ColeStatusresolved => closed

Notes
(0005071)
Brad King   
2006-09-29 16:43   
To help reduce the impact of this bug I've added support for a <CONFIG>_LOCATION property to GET_TARGET_PROPERTY:

/cvsroot/CMake/CMake/Source/cmTarget.cxx,v <-- cmTarget.cxx
new revision: 1.104; previous revision: 1.103
/cvsroot/CMake/CMake/Source/cmGetTargetPropertyCommand.h,v <-- cmGetTargetPropertyCommand.h
new revision: 1.10; previous revision: 1.9
(0028882)
Brad King   
2012-03-09 14:39   
As discussed in my original comments quoted in the description it does not make sense to get the LOCATION property at CMake time and expect a per-configuration value because no specific configuration has been chosen at CMake time.

Since this issue was last updated CMake's add_custom_command and add_test commands have gained support for "generator expressions" that are evaluated by the generators when the configuration is known. It resolves most of the need for use cases previously approximated by the LOCATION property and works on a per-configuration basis.

I'm resolving this as "not fixable" but it shouldn't need to be fixed anyway.
(0030831)
David Cole   
2012-09-03 16:00   
Closing resolved issues that have not been updated in more than 4 months.