[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#586512: kdelibs5-dev: Breaks installation of KDE apps into custom prefixes


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.

Reply to: