[CMake] How to query compiler definitions?

Michael Wild themiwi at gmail.com
Thu Jan 20 10:53:18 EST 2011


On 01/20/2011 04:30 PM, SF Markus Elfring wrote:
>> Probably that would be pretty difficult to achieve and definitely would
>> break backwards-compatibility beyond resurrection.
> 
> I have got a different opinion. I imagine that a property with a new
> name can provide the desired service to retrieve target parameters in a
> portable way from the build environment.
> Otherwise: Would the addition of a CMake command make more sense for
> this purpose?

A single property wouldn't do, you would need one for every
configuration and the "general" configuration, e.g.

- ALL_COMPILE_DEFINITIONS
- ALL_COMPILE_DEFINITIONS_DEBUG
- ALL_COMPILE_DEFINITIONS_RELEASE
- ALL_COMPILE_DEFINITIONS_MINSIZEREL
- ALL_COMPILE_DEFINITIONS_RELWITHDEBUGINFO
- plus other, user-defined configurations

These properties would need to read-only and available for directories,
source files and targets. That's a lot of work, but if it scratches your
itch, go ahead, get hackin' ;-)

> 
> 
>> You shouldn't check for a preprocessor symbol in CMake.
> 
> It's just the way I would prefer to adapt the build process to the
> requirements of the source files at the moment.
> 
> It seems that the evaluation of compilation parameters (variable
> "CMAKE_CXX_FLAGS...") with regular expressions is an approach that will
> currently work to some degree. The used pattern determines how many
> compilers will be supported.
> 

I don't think that the string NDEBUG is so common, so you could just
check for that and don't worry about the specific compiler flag.

> 
>> Instead, probably do a find_package(TinyXML)
> 
> I would appreciate if a corresponding module (search script) will become
> generally available for CMake.

You could write one ;-) You could also include a "private" version of
that script in your project and then append its location to the
CMAKE_MODULE_PATH variable.

> 
> 
>> and then depending on the result offer the user an option variable
> 
> I guess that the term "user" needs to be distinguished for its various
> meanings.
> 
> There are some switches involved that might only interest a subset of them.
> - software developers
> - system integrators
> - tool users
> 

User here means the dude who downloaded your package from SF and tries
to build it on his machine. :-) To hide uninteresting switches, you can
use the mark_as_advanced() command.

Michael



More information about the CMake mailing list