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

[Brian Davis]

C comments

On Tue, Aug 22, 2017 at 8:01 AM, Robert Maynard <robert.maynard at kitware.com>
wrote:

> Usage of link_directories is discouraged, and was part of the reason
> why a target based option was not added. As the documentation for
> link_directories states "Note that this command is rarely necessary.
> Library locations returned by find_package() and find_library() are
> absolute paths. Pass these absolute library file paths directly to the
> target_link_libraries() command. CMake will ensure the linker finds
> them."
>
>
Oh the horror.  We are not expected to have abs paths to our libs to ensure
"CMake finds them" vs supporting link library directories which all
compilers support for some reason.  I mean hey maybe CMake could support /
expose functionality of the underlying tools to the user in a way and means
that make sense and let them decide if abs paths or use of link libs dir is
appropriate.  I know which one I would choose.  Is it really that difficult
to make Link_directories a target specific property?

It's as though tying a remote control to a grandmother so as to "ensure"
she can turn on the TV is also a good idea.

I hope I never understand this logic.

Has any one read my post on ITK and use of abs paths where there is a 50
char limit imposed on where itk is built due to command line limitations on
windows for the build.  I am starting to understand how and why I now have
to build itk at C:/itk... I asked ITK if I should just build at c:\ but
they stated graciously something to the affect that I could  use those
extra 3 chars... boy was I happy then!

I ask that kitware read:

https://cmake.org/pipermail/cmake/2017-March/065227.html

and reassess logic of abs paths

Snips in line here for convenience:


-- snip --

But ITK is no great example either
as on windows has a limit due to path length limiting on where ITK can be
build (build dir) I think it's something like 56 characters (resulting in
build paths outside the project like C:\itk\src\ITK-4.8.1)  and I have
stated my aggravation regarding this on ITK's user forum.   I must be
joking right?  well from ITK root CMakeLists.txt file:

if( CMAKE_HOST_WIN32 )

  string( LENGTH "${CMAKE_CURRENT_SOURCE_DIR}" n )
  if( n GREATER 50 )
    message(
      FATAL_ERROR
      "ITK source code directory path length is too long (${n} > 50)."
      "Please move the ITK source code directory to a directory with a
shorter path."
      )
  endif()

Sadly no and .. ok so it's 50.

-- snip --

I would certainly like to hear a defense of this "logic". I like to say
that I discourage insanity.




On Mon, Aug 21, 2017 at 8:17 PM, Brian Davis <bitminer at gmail.com> wrote:
> > Why does:
> >
> > Interface Libraries
> > https://cmake.org/cmake/help/latest/command/add_library.
> html?highlight=add_library#id3
> >
> > allow include directories via
> >
> > target_include_directories(INTERFACE)
> >
> > but not link_directories
> >
> > https://cmake.org/cmake/help/latest/prop_dir/LINK_
> DIRECTORIES.html?highlight=link_directories
> >
> > which if we look at property scope:
> >
> > https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html
> >
> > Why is include_directories at target resolution while link_directories
> is at
> > directory resolution.
> >
> > link_directories is a property on a directory which if I recalled
> correctly
> > I complained about many many moons ago (circa 2009) when I first realized
> > this.  I did not understand this logic then and don't understand this
> logic
> > now.  Someone what to give me the recipe for the CMake cool-aid so I can
> mix
> > that up, drink it down, and re-read the doc and finally come to terms
> with
> > this.  Or could the powers that be redesign CMake to make sense.  At the
> > time I wrapped this nonsense in a macro and pretended it did not happen
> ...
> > now I am rewriting my project for "new" CMake and still don't get this.
> >
> >
> >
> >
> > --
> >
> > 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
>



-- 
Brian J. Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170822/450e73bd/attachment-0001.html>