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