[CMake] How to query compiler definitions?

[Michael Wild]

On 01/19/2011 02:41 PM, SF Markus Elfring wrote:
>> You don't seem to understand the difference between CMake-time and Make-
>> (or build-) time.
> 
> I understand that there can be differences between the time of
> configuration and the applied generation. I guess that we have got
> different expectations about the introspection capabilities of the CMake
> build system.
> 
> 
>> Build-time is when the actual build system runs.
>> Everything is static here (except for custom commands).
> 
> I do not want it this way for my use case.

Then CMake is not the right tool for you ;-) This would require the
configure+generation step to occur at the same time as the build step.

> 
> 
>> In particular, you can't change the list of source files any more.
> 
> I imagine that the build system can still accommodate to some changes
> from other sources like preprocessor symbols.

You could ask for a source-file property to that effect. E.g.

set_source_files_properties(debug_funcs.c PROPERTIES
  EXCLUDE_FROM_CONFIGURATIONS "Release;MinSizeRel")

which would cause debug_funcs.c only to be compiled for the not-excluded
configurations. I don't think it would make to do this based on
preprocessor definitions.

> 
> 
>> The problem is, you want to assemble that list at build-time, which is
>> not possible, because then CMake wouldn't know about them.
> 
> Can instructions from CMake scripts also be executed at generation time?

Only scripts that are run through add_custom_command or
add_custom_target, but they are really isolated scripts (think bash or
python), they don't have any feedback on the build system.

> 
> 
>> I don't quite understand why it is so important to you that these files
>> aren't passed to the compiler. If you exclude all of their contents with
>> "#ifndef NDEBUG", then each file should take less than a second to
>> compile, so you'd need a lot of those debug-only files for it to matter.
> 
> I hope that a more detailed description will clarify my use case.
> 
> Example:
> A source file "toy.cxx" contains already the preprocessor switch that
> you mentioned. The marked debug code works with objects from a C++ class
> library for XML processing which has got its bunch of source files
> bundled in this project. Now I would like to omit this dependency if the
> software will be built for "release" mode. I would also like to be sure
> and want to check before the call of a compiler if this special symbol
> is really set.
> 
> Regards,
> Markus

So, toy.cxx is not actually the problem, but you don't want to link
against the XML library. Do you need the library anyways (e.g. for other
targets) or does the whole project only require this library for this
debugging code? The question is, would something like this do for you
(here I assume the library you need is libxml)?

-----------<8------------

find_package(FindLibXml2 REQUIRED)
include_directories(${LIBXML2_INCLUDE_DIR})
if(LIBXML2_DEFINITIONS)
  add_definitions(${LIBXML2_DEFINITIONS})
endif()

add_executable(super a.cxx b.cxx c.cxx toy.cxx)
target_link_libraries(super foo bar debug ${LIBXML2_LIBRARIES})

add_executable(duper d.cxx e.cxx)
target_link_libraries(duper ${LIBXML2_LIBRARIES})

-----------<8------------

Like this you only link the target super against the libxml libraries
for debug configurations. Since target duper always needs libxml, it's
ok to require it always.

However, if libxml is required for debugging only and you don't want to
require it unconditionally, you have a problem and I can't see an easy
way around it.