tldr;
It would be wonderful to have function or signature for
target_link_libraries tha would link only to a targets. Did I overlook
something?
like target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ...
QUIET/VERBOSE)
(*read with the voice of a child*)
Dear CMake developers, dear Santa
I wish you could make the mess of using "fake namespace" notation go
away. I no longer know what to link to when i write
find_package(myFavouriteLib). In cmake 2.6, 2.8 there was a set of
variables, which you need to get from the FindmyFavouriteLib.cmake.
Smart people used MYFAVOURITELIB_INCLUDE_DIR and
MYFAVOURITELIB_LIBRARY. Well sometimes a plural but mostly just that.
Then there came the targets. A really nice way of packing all the
things together and then it mostly got even simpler - link to the same
string you provided to the find_package. So myFavouriteLib or in case
of having a COMPONENTS a 'componentName'. But some spooky people were
constantly making mistakes about not checking their targets and so for
the sake of the backward compatibility with the target_link_libraries
someone brought a "fake namespace" to once again break the backward
compatibility. Some of the libraries changed the string to link to
again from myFavouriteLib to myFavouriteLib::myFavouriteLib (e.g.
assimp, and thanks to my colleague for that, but their cmake config
never really worked anyway) which is horribly long and now I need to
change every cmake that uses it. Well in some cases I changed only the
custom find module but since I can't effectively alias imported
targets (that aren't globaly vissible, wtf) nor I could clone them
(WH?, did I again overlook something) it was a hell and the
code is unnecesserily long. But now once again I don't know what to
link to when calling find_package. It could be anything from
myFavouriteLib, myFavouriteLib::myFavouriteLib,
myFavouriteLib::component, MFL::component, component, and more (glm,
Qt, OpenSceneGraph...). The programmers (myself included) seldomly
have a time to write a proper documentation for their libraries (like
Qt or Java do) and moreover this goes for documenting their cmake
behaviour. So I once again need to go through the code to realy find
what to link to. What a mess.
But then I guess it wouldn't hurt to have something like
target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ...
QUIET/VERBOSE) which would not try to give linker myFavouriteLib.lib
if there was no target of that name in question. Or
target_link_targets... realy doesn't matter as long as it does that
and maybe when asked by the last parameter it gives an error if the
one of the target is non-existent or ill-formed. And maybe then after
couple of years when the dusts settles (after otherwise great talk
from Daniel Pfeifer on cppCon) we could see the cmakes that when you
know the name of the library, you don't need to search throu the code
to find what you are supposed to link to like glm.
Eventhough this doesn't look like it, it is just a short 'story' to
pinpoint, from my perspective, one of the biggest flaw in one great
configuration system. There could be done lot of the arguments for
every thing I mentioned and lot's of problems that I for sake of
simplicity didn't. After 10 years of using cmake and couple of years
of trying to teach it to people that knows only a makefile and
sometimes a bit about MSVC I came across a lot. And for me this class
of problems boils down to the inconsistency between the find_package
call and what you get from it. I now that it is great, that librety of
doing what ever you want in that config script, but...
Hope I don't spark a flame war about the naming conventions. I would
like this proposal to be calmly considered. In best case just say that
I'm an idiot and there is exactly that feature since 3.x.x.
Best regards
forry
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
