[CMake] 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