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 (WHYYYYYYYY?, 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

Reply via email to