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