Hello, On sekmadienis 20 Birželis 2010 12:44:32 Modestas Vainius wrote: > On sekmadienis 20 Birželis 2010 11:51:54 Andreas Pakulat wrote: > > it seems that Debian patches FindKDE4Internal.cmake to disable cmake's > > behaviour of setting up RPATH for installed executables. This breaks any > > KDE app using libraries installed into a custom prefix (like > > $HOME/myapp) as then those shared libs are not found anymore. IIRC the > > reason this was done was because apps installed into /usr shouldn't have > > any RPATH set. There was a related discussion on the kde-buildsystem > > list and (again IIRC) the outcome was that recent versions of cmake only > > set setup the RPATH when the install prefix of the libraries is not > > /usr. > > > > Hence the applied patch should be removed again so that people can build > > and install KDE apps from sources again without fiddling with cmake > > files or cmake's cache. > > The patch is not going to be removed. But I believe I can make it less > extreme by replacing it with the one in kdelibs trunk [1]. It should solve > your problem and my issues with original FindKDE4Internal.cmake. > > [1] http://websvn.kde.org/?view=revision&revision=1124215 What is more, I don't like how KDE pretends to be so smart. It should not touch those CMAKE_* global settings at all leaving them for the user to choose. What would happen if all find_package(...) messed with global RPATH settings like KDE does? However, a single warrior in the battlefield can't win the war. -- Modestas Vainius <modestas@vainius.eu>
Attachment:
signature.asc
Description: This is a digitally signed message part.