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

Wed Aug 23 03:07:03 EDT 2017

I can't argue too much why paths or absolute on cmake as I don't know the
rationale behind it is. While your point about command line limit makes
sense, I feel like a system limiting command line size to this extent is
dumb if it doesn't allow reading more arguments through a file. (again, I
don't know the system at all).
I kinda understand your point about not being able to set the libdir per
target but (might have missed it in your previous mails) I don't know what
kind of project would need that. At best I would need one version of the
library per configuration, which is supported.

I entirely agree with for the rest. CMake badly documenting good practices
or even giving tutorials is an issue. Probably the biggest issue I found. I
myself still fight after years of using and experimenting with it. This
lead to a plethora of badly written cmakelists.txt or module scripts, that
even people in this list still advocates without understanding the problems
behind it. Even some tutorial series found on github.com or used by
coverage websites do it wrong.

At the moment the only reference I trust is Daniel's presentation and some
of the internal cmake scripts.

While not solving your problem, I documented most of my findings in this
small template /reference https://github.com/Lectem/cpp-boilerplate (which
might still do things the wrong way)

Le mer. 23 août 2017 à 02:14, Brian Davis <bitminer at gmail.com> a écrit :

> 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.
>
>
> --
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170823/44d8e9c5/attachment-0001.html>