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.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
