[CMake] granular preprocessor defiitions

Christoph Anton Mitterer calestyo at scientia.net
Thu Apr 5 19:24:56 EDT 2012


Hi Brad.

Tanks for your insights :)

>add_definitions is the original interface and uses -D in its syntax 
> for
>historical reasons.  The earliest quick-and-dirty implementation 
> allowed
>arbitrary flags so people started abusing it.  Then we had to support
>such projects for compatibility.
I understand why it came to that "mess"[0]... but given that you have 
this wonderful mechanisms of policies... it should be rather easy to 
clean up such historical stuff up and slowly phase the old and unclean 
ways out.

But right now the documentation more or less even implies, that it 
should be used for any flags ("This command can be used to add any 
flags, but it was originally intended to add preprocessor definitions.")


>These days you can set the COMPILE_DEFINITIONS property on a 
> per-directory,
>per-target, and per-source basis (and even per-configuration):
>  
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_dir:COMPILE_DEFINITIONS
>  
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:COMPILE_DEFINITIONS
>  
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_sf:COMPILE_DEFINITIONS
>CMake 2.8.8 adds support for per-target INCLUDE_DIRECTORIES.
That sounds highly interesting...


OT:
But it brings up two general problems I yet have with CMake...
a) I've already read quite some documentation about it (mostly the 
manpages) but at least I still miss the whole picture and intentions 
behind everything.
- E.g. the CONFIGs... what's their idea,.. how does it work in general
- the properties,... are they intended to replace the many special 
variables (with special names)
- subtle differences or whether something is deprecated, e.g. 
CMAKE_PRJECT_NAME vs. PROJECT_NAME
- how inheritance works on add_subdirectory() and include(),... for 
both, variables and properties
- scope questions

b) How I'm intended to do many things, e.g.
- how to find libraries? Is find_library generally preferred? Or shall 
one use find_package or that + the pkg-config if available ?
- same for includes
- shall I collect my libs / includedirs in variables and then call e.g. 
target_link_library once, or is it the same to call target_link_library 
for every lib I want to link
- etc. etc.
- also for some commands I have no idea for what I could use them... 
some already name typical tasks in their documentation, which I consider 
very helpful.
- also it's usually difficult to know which ways have been deprecated 
and which are "the future"

I guess it's clear that it's quite easy with CMake to get something 
build.
But IMHO, understanding the big picture and the intended ways (I mean 
you guys are the experts in terms of build systems and you surely have 
something in mind with what you've written) would probably help one to 
make everything better :)


But back to the above,.. so I'd assume the following:
- generally no need to add include dirs for system header files (e.g. 
POSIX and libc stuff).
- for own libraries or non-system libs (e.g. libssl)... which would I 
use (if I already had 2.8.8),... rather trying to narrow down all 
includes to each give source file? Or setting things more broadly either 
per dir or target?


Chers,
Chris.


[0] Again, no one shall be felt offended,... I really like cmake :)


More information about the CMake mailing list