On Tue, Aug 22, 2017 at 12:42 PM, Clément Gregoire <lec...@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