MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015374CMakeCMakepublic2015-01-27 10:142016-06-10 14:31
Reporterraspy 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
Platformx86_64OSRedHat Enterprise LinuxOS Version6.4
Product VersionCMake 3.1 
Target VersionFixed in Version 
Summary0015374: Support generator expresssions in add_definitions()
DescriptionGenerator expressions are supported in add_compile_options(), target_compile_options() and target_compile_definitions(), but not in add_definitions() which leads to some inconsistency. I would make use of generator expressions in definitions on a global level, mostly define some symbols based on CMake's variables setup.

Please add support for generator expressions in add_definitions().
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-01-27 10:14raspyNew Issue
2015-01-27 10:18Nils GladitzNote Added: 0037837
2015-02-01 11:59Stephen KellyNote Added: 0037874
2015-02-02 04:07raspyNote Added: 0037878
2015-02-03 09:48Brad KingNote Added: 0037885
2016-06-10 14:29Kitware RobotNote Added: 0042704
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0037837)
Nils Gladitz   
2015-01-27 10:18   
In the meantime you can work around the issue by directly using the underlying COMPILE_DEFINITIONS directory property (which supports generator expressions).
(0037874)
Stephen Kelly   
2015-02-01 11:59   
I avoided adding genex support to this command so far for fear of the -D required at the beginning of entries. Content like

 add_definitions($<1:-DFOO>)

can not be just added to the COMPILE_DEFINITIONS property, which expects no -D prefix. The prefix would have to be processed and removed at generate time.

Resolving this issue will probably require designing the future for that command. Maybe it shouldn't require/accept the -D? I don't know, and haven't designed anything, but anyone else is welcome to.
(0037878)
raspy   
2015-02-02 04:07   
I think that this command should follow the semantics of target_compile_definitions. At least it should not take -D when using generator expressions, this would make it consistent with other uses target_compile_definitions.

Since passing other options through add_definitions is not encouraged in favor of use add_compile_options, CMake could perhaps make use of a new policy to only allow definitions (without prefixes). As an alternative it could also assume that any argument not starting with a hyphen or a slash is actually a definition, so that:

add_definitions(-DFOO)

and

add_definitions(FOO)

mean the same. This would make easier to introduce syntax:

add_definitions($<1:FOO>)

without further implications of stripping -D prefix.
(0037885)
Brad King   
2015-02-03 09:48   
We could also consider creating a new "add_compile_definitions" command to supersede add_definitions for maintaining the directory-level COMPILE_DEFINITIONS property.
(0042704)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.