[CMake] Interface Libraries allow include directories but not link directories.. Why?

[Brian Davis]

On Tue, Aug 22, 2017 at 12:42 PM, Clément Gregoire <lectem at gmail.com> wrote:

> No you're not meant to specify paths yourself, you should just use
> find_library.
> Check how modules such as FindTIFF.cmake are implemented.
>

Please doc in CMake all the things I am "meant to" so as I can live inside
that happy little bubble world.

Did I not just provide a perfectly rational reason why a crazed end user
may want set lib path... err.... themselves

/LIBPATH: is there for a reason in the compiler / linker sadly it appears
CMake does not get this.  Clearly like the toolchain developers thought it
was a good idea... hmm wonder it it had anything to do with the command
line length problem?  Ahh yes must be a pesky little throwback from the
days of yore.  Full paths eureka!  Nope not buying it.

It appears CMake wants to save me from myself by not allowing me to set
LIBPATH.  I mean do I got this right?  If so who's going to save CMake from
themselves?

Hey why not completely save me from myself and take away
target_include_directories.

I find find_library (I tried it and had in the past) still yields full path
for every library even if multiple libs are in same dir and is even
documented as such:

https://cmake.org/cmake/help/latest/command/find_library.html?highlight=find_library

"If the library found is a framework, then <VAR> will be set to the full
path to the framework <fullPath>/A.framework. When a full path to a
framework is used as a library, CMake will use a -framework A, and a
-F<fullPath> to link the framework to the target."

When these full lib dirs are chucked at the linker .... kerpow... if large
paths are used where project is located.


But hey if find_library or whatever insanity I should use would say use a
parameterized variable other than what is currently:

find_library(
   MY_LIB_DEBUG
   NAMES 4DFUtilities.lib
   HINTS C:/projects/4DRTProto/4DRTProto/build/x64/Debug
)

FUORO4D_UTILITY_LIB_DEBUG =
C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib

but rather generate a paramaterized version:

FUORO4D_UTILITY_LIB_DEBUG =
"LIBRARY_NAME;4DFUtilities.lib;LINK_DIRECTORY;C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries"

(above is goop I have had to resort to <at this rate may still have to> in
CMake and VARARG macros for some  resemblance of inherited build properties
prior to interface libraries)

Then prior to command generation for linker *could* through the power of
filtering for unique strings search all those LINK_DIRECTORY paths
specifications and retain unique and set that crazy elusive, never to be
gazed upon by human eyes, it-who-must-not-be-named /LIBPATH flag.  Doesn't
that little cursor have enough to do with out dancing all over the place
printing out full paths to libraries... I mean give the little bugger a
break will ya!

Let me be clear.  There are two problems here:

1) Abs paths to link libraries causing command line length issues such as
in ITK
2) Inability to set lib dirs at target resolution.  find_library which is
suggested a solution to this could be *if* it did not force abs paths to
libs and would rather gather up unique full paths and set /LIBPATH

There may only be one problem here.   If find_library worked as I suggest
then there would be zero problems here... with the exception that
CMAKE_VARIABLES such as what find_library generates are so 2.8.12 (ref:
https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf)
and not "Targets" and "Properties" which if we had
target_link_directories... would be! (CMake could even add find capability
if desired) As per my new sense of sensibilities in the new CMake era
frankly I find find_library to be the old backwards way of doing this...
not that it does it correctly in the first pace... never has.

And don't get me started on the FindWhatevers and CMake Packaging ... ohhh
that's coming!  Consider that worm can open.... I have already started to
post some bits on that insanity, the lack of direction and features in
CMake (project VERSION not appending to CMAKE_INSTALL_PREFIX so as not to
blast away prior installed versions), inconsistent CMake documentation
(lack of lib and include dir versioning and standard location of where to
put .cmake package files), and  3rd party package devs do whatever they
want mantra, and the end user experience.  If CMake really wants to save
me... save me from the 3rd party package developers miss use of CMake by
fixing and better documenting CMake.  3rd party package devs only do what
they think is right and what they can get away with based on poor doc and
impl.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170822/2365ff0b/attachment.html>