link only with targets feature

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

link only with targets feature

Starka Tomáš
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 | Threaded
Open this post in threaded view
|

Re: link only with targets feature

Alexander Neundorf
On 2019 M02 12, Tue 08:02:43 CET Starka Tomáš wrote:
> 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)
>
...
> 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.

I agree to target_link_targets().
Additionally I would prefer if (maybe with a policy) include directories would
be only applied when using target_link_targets(), but not when using
target_link_libraries().
This would make it more obvious IMO.

Alex

--

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