New dependency for kdelibs and kdebase: dbusmenu-qt

[Alexander Neundorf]

On Tuesday 04 May 2010, Modestas Vainius wrote:
> Hello,
>
> On antradienis 04 Gegužė 2010 23:03:35 Alexander Neundorf wrote:
> > On Tuesday 04 May 2010, you wrote:
> > > 2010/5/4 Alexander Neundorf <neundorf at kde.org>:
> > > > It really depends on what you as the maintainer of this package want.
> > > >
> > > > No RPATH means that e.g. Qt has to be found either via the env. var
> > > > LD_LIBRARY_PATH, or it is installed in a location which is searched
> > > > anyway by the linker (loader), so e.g. /usr/lib or a directory
> > > > configured in /etc/ld.so.conf.
> > >
> > > At least in Debian the use of RPATH is discouraged, see
> > > http://wiki.debian.org/RpathIssue for the rationale. At least provide
> > > a configurable option to turn off rpath if it is made the default.
> >
> > There is nothing to do, cmake itself provides a cache variable
> > CMAKE_SKIP_RPATH, which is FALSE by default, but which you can set to
> > TRUE via "make edit_cache", then no RPATHs will be in the installed
> > binaries.
>
> Just for the record, I had to patch out your too excessive RPATH handling
> in KDE 4.4 packages for Debian. 

Somehow I feel like the tone of this email could have been even friendlier...

Sorry that "my excessive RPATH handling" is not good enough for Debian.

> If you think that CMAKE_SKIP_RPATH=ON is an
> ultimate solution to the problem, you are mistaken. 

Again sorry that I'm too stupid.

> We have a perfectly 
> valid use cases for RPATH/RUNPATH so skipping RPATH completely is not an
> option esp. if it is suggested to be done blindly. /usr/lib in RPATH is a
> bug for which Debian packages may get rejected before they even enter the
> archive.
>
> However, I have already seen the light in the tunnel with such code in
> akonadi trunk:

How to put it.
I wasn't aware that we have currently an issue with debian packaging.
It would have helped if you would have brought up this issue again on 
kde-buildsystem (or here on k-c-d).
Or, you could even have proposed a patch. Or, you have a svn account, 
committed something to KDE4Macros.cmake.

The even better way would have been to post an email to the cmake list or to 
the cmake bugtracker to request that these directories 
(CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES) don't get included when using 
INSTALL_RPATH_USE_LINK_PATH.
So not just KDE, but any cmake-using project automatically would benefit.


> list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${LIB_INSTALL_DIR}"
> _isSystemLibDir)
> if("${_isSystemLibDir}" STREQUAL "-1")
>   set(CMAKE_INSTALL_RPATH "${LIB_INSTALL_DIR}")
> endif("${_isSystemLibDir}" STREQUAL "-1")
>
> I really hope that something like this has been implemented in the rest of
> KDE trunk as well (I have not checked). 

So please do, and if you're not satisfied, please post a patch.

Alex