<p dir="ltr">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). <br>
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. </p>
<p dir="ltr">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 <a href="http://github.com">github.com</a> or used by coverage websites do it wrong. </p>
<p dir="ltr">At the moment the only reference I trust is Daniel's presentation and some of the internal cmake scripts. </p>
<p dir="ltr">While not solving your problem, I documented most of my findings in this small template /reference <a href="https://github.com/Lectem/cpp-boilerplate">https://github.com/Lectem/cpp-boilerplate</a> (which might still do things the wrong way) <br>
</p>
<br><div class="gmail_quote"><div dir="ltr">Le mer. 23 août 2017 à 02:14, Brian Davis <<a href="mailto:bitminer@gmail.com">bitminer@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 22, 2017 at 12:42 PM, Clément Gregoire <span dir="ltr"><<a href="mailto:lectem@gmail.com" target="_blank">lectem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">No you're not meant to specify paths yourself, you should just use find_library. <br>
Check how modules such as FindTIFF.cmake are implemented. </p>
</blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Please doc in CMake all the things I am "meant to" so as I can live inside that happy little bubble world.<br><br></div><div>Did I not just provide a perfectly rational reason why a crazed end user may want set lib path... err.... themselves<br></div><div><br></div><div>/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.<br><br></div><div>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?<br><br></div><div>Hey why not completely save me from myself and take away target_include_directories.<br></div><div><br></div><div>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:<br><br><a href="https://cmake.org/cmake/help/latest/command/find_library.html?highlight=find_library" target="_blank">https://cmake.org/cmake/help/latest/command/find_library.html?highlight=find_library</a><br><br>"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."<br><br>When these full lib dirs are chucked at the linker .... kerpow... if large paths are used where project is located.<br><br></div><div><div id="m_6291746658147828811gmail-:231" class="m_6291746658147828811gmail-Ar m_6291746658147828811gmail-Au m_6291746658147828811gmail-Ao" style="display:block"><div id="m_6291746658147828811gmail-:236" class="m_6291746658147828811gmail-Am m_6291746658147828811gmail-Al m_6291746658147828811editable m_6291746658147828811gmail-LW-avf" style="direction:ltr;min-height:85px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>But hey if find_library or whatever insanity I should use would say use a parameterized variable other than what is currently:<br><br></div><div>find_library( <br>   MY_LIB_DEBUG <br>   NAMES 4DFUtilities.lib<br></div><div>   HINTS C:/projects/4DRTProto/4DRTProto/build/x64/Debug<br>)<br></div><div><br></div></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature">FUORO4D_UTILITY_LIB_DEBUG = C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib<br><br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature">but rather generate a paramaterized version:<br><br>FUORO4D_UTILITY_LIB_DEBUG = "LIBRARY_NAME;4DFUtilities.lib;LINK_DIRECTORY;C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries"<br><br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature">(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)<br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature"></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature"><br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature">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!<br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature"><br>Let me be clear.  There are two problems here:<br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature"><br>1) Abs paths to link libraries causing command line length issues such as in ITK<br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature">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<br><br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature">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: <a href="https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf" target="_blank">https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf</a>) 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.<br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature"><br>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.<br><br></div><div class="m_6291746658147828811gmail-m_-6933285302401221194gmail_signature"><br></div></div></div></div></div></div>
</div></div>
--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a></blockquote></div>