<div dir="ltr">It's also handy to get installation paths from GNUInstallDirs<br><br><a href="https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html">https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html</a>  especially if you expect to install libs on linux which either go to lib or lib64.<br><div><br></div><div>many things that install to windows just supply a standard base path (/program files/<your app>) and then still use bin, lib, share, etc in that path...</div><div><br></div><div>It is an annoyance to have to override dll installation to bin instead of lib on windows....</div><div><br><div>include( GNUInstallDirs )</div><div><br></div><div>if( WIN32 )<br></div><div>    set( BINARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} )<br></div><div>    set( SHARED_LIBRARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} )<br></div><div>    set( SHARED_LIBRARY_LINK_DIR ${CMAKE_INSTALL_LIBDIR} )<br></div><div>else( WIN32 )<br></div><div>      set( BINARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} )<br></div><div>      set( SHARED_LIBRARY_OUTPUT_DIR ${CMAKE_INSTALL_LIBDIR} )<br></div><div>      set( SHARED_LIBRARY_LINK_DIR ${CMAKE_INSTALL_LIBDIR} )<br></div><div>endif( WIN32 )<br></div><div><br></div><div>and then use the aliased path instead</div><br><div>macro( install_my_thing )</div><div><span style="white-space:pre">        </span>install( TARGETS ${ARGV}<br></div><div><span style="white-space:pre">            </span>RUNTIME DESTINATION ${BINARY_OUTPUT_DIR} <br></div><div><span style="white-space:pre">          </span>LIBRARY DESTINATION ${SHARED_LIBRARY_OUTPUT_DIR}<br></div><div><span style="white-space:pre">            </span>ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} )<br></div><div>endmacro( install_my_thing )<br></div><div><br></div>People will inevitably also respond and say 'but dlls install as runtime' which is probably true these days.  All I can do is copy the cmake stuff I have that definitely works; which has been around since 2.6 or something...</div><div><br></div><div>So it's probably simpler than what I've shared above.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 27, 2017 at 4:08 AM, Eric Noulard <span dir="ltr"><<a href="mailto:eric.noulard@gmail.com" target="_blank">eric.noulard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2017-07-27 12:28 GMT+02:00 David Demelier <span dir="ltr"><<a href="mailto:demelier.david@gmail.com" target="_blank">demelier.david@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I'm still trying to find a correct solution to handle user specified installation paths.<br>
<br>
Let's consider two kind of paths:<br>
<br>
  - WITH_BINDIR (default: bin/) where to install executables,<br>
  - WITH_DATADIR (default: share/project_name/) where to install extra data.<br>
<br>
I want to let the user configuring those paths because not all distributions use the same paths (e.g. bin vs usr/bin).<br>
<br>
Then, I also like to build the whole CMake project by creating the hierarchy as it would be installed like:<br>
<br>
<binarydir>/WITH_BINDIR/myapp<br>
<binarydir>/WITH_DATADIR/somes<wbr>tuff.txt<br></blockquote><div><br></div></span><div>Do you mean here that you setup CMAKE_<XXXX>_OUTPUT_DIRECTORY (variable or target property) to your favorite value</div><div>or</div><div>You build and then install with the <binarydir>/ prefix?</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Using relative paths makes the application relocatable, if I keep WITH_BINDIR set as "bin" I can get the executable path at runtime, going through its parent (bin/../) and then I can go share/project_name. Obviously this is only valid for relative paths.<br>
<br>
However, a very high number of package managers build programs by specifying absolute paths, it is not an issue: instead of getting the directories at runtime, I use directly the absolute ones.<br>
<br>
On unix it can still work because it will just be translated as:<br>
<br>
<binarydir>/usr/local/bin/myap<wbr>p<br>
<binarydir>/usr/local/share/pr<wbr>oject_name/somestuff.txt<br>
<br>
This is much bigger an issue on Windows if the user set WITH_BINDIR to something like D:/alt/bin<br>
<br>
The path would be translated to<br>
<br>
<binarydir>D:/alt/bin<br>
<br>
which is invalid on Windows.<br>
<br>
I like very much having this kind of `fakeroot' directory where you can have a preview on how the project looks like but I don't know what to do if paths are absolute, especially on Windows.<br></blockquote><div><br></div></span><div>My opinion is that you should never use absolute path (besides some very specific case on unix where you want to put something in /etc/...)</div><div>You should ask your user for</div><div><br></div><div>   DATADIR</div><div>   BINDIR</div><div>   etc...</div><div><br></div><div>all those var should be relative path.</div><div><br></div><div>and an eventual</div><div>   INSTALL_PREFIX</div><div>which could be absolute.</div><div><br></div><div>In any case if you really want to tolerate absolute path given by the user, but still want to mimic install location during the build</div><div>then you'll have to escape it.</div><div><br></div><div>For each path you expect from the user:</div><div><br></div><div>check the path with if(IS_ABSOLUTE path) and compute some relative path</div><div>  a) if you are on Windows remove the drive letter, i.e. D:/alt/bin becomes alt/bin</div><div>          (or network drive share name //shairedisk/alt/bin  becomes alt/bin)</div><div>  b) if you are on Unix </div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What are your thoughts on that, recommandations?<br></blockquote><div><br></div></span><div>I wouldn't try to mimic install tree during the build (if it is what you are doing),</div><div>If I have a need to "verify" install tree structure then **after the build** I would do a fake install with a particular</div><div>local prefix (as CPack does before packaging).</div><div><br></div><div>Note that for similar reason CPack has to track files installed with absolute destination and</div><div>possibly error out when it cannot handle it, particularly on Windows oriented generator:</div><div>see e.g.:</div><div><a href="https://cmake.org/cmake/help/v3.7/variable/CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION.html" target="_blank">https://cmake.org/cmake/help/<wbr>v3.7/variable/CPACK_ERROR_ON_<wbr>ABSOLUTE_INSTALL_DESTINATION.<wbr>html</a><br></div><div><br></div><div>AFAIK, IFW and NSIS do not work with, absolute installed files.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_5484883303340005435gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div>
</font></span></div></div>
<br>--<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/<wbr>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/<wbr>support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>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/<wbr>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/<wbr>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/<wbr>mailman/listinfo/cmake</a><br></blockquote></div><br></div>