setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

Alexander Neundorf neundorf at kde.org
Wed May 23 20:31:49 UTC 2012


On Friday 11 May 2012, Alexander Neundorf wrote:
> On Friday 11 May 2012, Patrick Spendrin wrote:
> ...
> 
> > Hm, I think I misunderstood something in the beginning. There actually
> > still is a difference between CMAKE_RUNTIME_OUTPUT_DIRECTORY and
> > EXECUTABLE_OUTPUT_PATH - according to the documentation of cmake,
> > CMAKE_RUNTIME_OUTPUT_DIRECTORY supercedes EXECUTABLE_OUTPUT_PATH which
> > leads to the following problematic layouts:
> > 
> > if we do not set RUNTIME_OUTPUT_DIRECTORY but only
> > EXECUTABLE_OUTPUT_PATH, libraries will end up whereever they come from
> > on windows which requires additional path calculations etc.
> > 
> > if we do set RUNTIME_OUTPUT_DIRECTORY, we move all libraries &
> > executables into one dir on Windows, and on linux we do keep all the
> > libraries where they are (or set LIBRARY_OUTPUT_DIRECTORY) but we still
> > just put all executables into one directory.
> 
> Yes, setting only one of those variables is not enough. We have to make
> sure both libs and executables go into one directory, e.g.
> ${CMAKE_BINARY_DIR}/bin/ under Windows.
> 
> > I have no idea about the rpath stuff, but iirc there was some resetting
> > of rpath going on when running make install to fix the different needs?
> 
> On systems with RPATH, with cmake you get by default a full RPATH (i.e.
> containing the directories of all libraries you linked against) in the
> build tree. During make install, the RPATH entry in the ELF file is
> patched and the build RPATH is replaced with the install RPATH.
> CMake also takes care that if the build RPATH is shorter than the install
> RPATH, additional room is reserved so that the install RPATH will fit.

I removed the
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR})
now in all projects in tier1/.
Those variables are set now (since 0.0.4) in extra-cmake-modules, 
KDECMakeSettings.cmake.
Under Windows they are set to ${CMAKE_BINARY_DIR}/bin/, otherwise they are 
unset, so everything should be simply built in the current directory.

Let me know if something breaks.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120523/1ae5fe5e/attachment.html>


More information about the Kde-frameworks-devel mailing list