[CMake] granular preprocessor defiitions

[Christoph Anton Mitterer]

Hi.

I thought a bit more about this as well as packages that find libs and 
played around with find_library()...

Apart from what you already noted (about runtime libs and technical 
issues) I think the following would be necessary (from the interface 
point of view, not the technical way how to implement):

- target_link_library()
As long as you allow that people specify library names (i.e. the XXX in 
-lXXX) and not only full paths, either of the two could be done:
a) say that there is no support for choosing static/dynamic linking but 
the default is always chosen by the respective toolchain.
b) add keywords as I proposed in the beginning (as you noted, this 
would be just required for -lXXX and not full pathname arguments)


- find_library()
a) Here, I think, we need flags if we want to be able to portable 
search for static or shared libs. Otherwise one would have to specify a 
full (non-portable) name like libXXX.so/.a.
Not sure what should be done if no flag is given, as far as I can see, 
right now it always searches for the shared lib, right?
On could either say if nothing given, always use shared and fail if 
that is not found, or first search for the shared, then as fallback for 
the static.

b) I was quite surprised to find out that find_library() not only 
supports specifying library names (e.g. the XXX in libXXX.so) but also 
full (non-portable) names.
Isn't that possibly ambiguous? E.g. if I search find_library(bla 
libfoo.so)... ok this probably never happens, but what if someone calls 
his lib stupidly "libfoo.so" yielding in a liblibfoo.so.so) on *NIX?
Which of the two would now be found?

So,.. maybe I oversee something, but IMHO the best solution was if 
find_library ONLY allows (or expects) library names (e.g. the XXX in 
libXXX.so) as parameter. This would also be consistent, because if 
someone wants to search for the file "libfoo.so" he should probably use 
find_file().
Of course this probably breaks backwards compatibility.


- packages/imported/exported/etc stuff
I just picked a few of the FindXXX.cmake files by chance, and most of 
them gave
XXX_FOUND
XXX_LIBRARIES

a) If one want's to support the static and shared versions of one 
library, than this is not enough, is it?
One would need
XXX_STATIC_FOUND
XXX_SHARED_FOUND
and
XXX_STATIC_LIBRARIES
XXX_SHARED_LIBRARIES
(the later two, if the give the full path, and not just the -l names).

b) It seems that there are still some modules which return just the 
name, not the paths.



I'm not a linking expert... are there special things needed to be taken 
into account when a library shall be dynamically loadable (i.e. dlopen() 
)...?
I thought these were just normal shared objects but you also have the 
MODULE parameter in add_library().
So if they're special, all the above would have to be extended for that 
as well (in order to gain real portability).
That means if I'd say something like find_library(bla XXX MODULE) a 
check would be run whether the found lib can be dynamically loaded and 
one would have
XXX_MODULE_FOUND
XXX_MODULE_LIBRARIES
in addition.


Hope it makes sense what I write ^^


Chris.