C comments On Tue, Aug 22, 2017 at 8:01 AM, Robert Maynard <[email protected]> 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 <[email protected]> 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
-- 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
