New dependency for kdelibs and kdebase: dbusmenu-qt

[Alexander Neundorf]

On Wednesday 05 May 2010, Modestas Vainius wrote:
> Hello,
>
> On trečiadienis 05 Gegužė 2010 21:25:16 Alexander Neundorf wrote:
> > 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.
>
> Don't put it like that, this was not personal. However, it is also true
> that RPATH changes were typically done by you (according to svn blame)
> throughout KDE (mostly due to your setup as far as I can tell) so this
> comment ended up kind of directed at you.

Well, because most of the "core" buildsystem stuff is done by me. ;-)

...
> I also think that cmake itself could benefit from more smart RPATH handling
> like that. That stuff in akonadi trunk (which I found completely by
> accident btw) is completely acceptable solution and as I said before, if it
> was deployed in the rest of KDE/kdesupport, I would have nothing to
> complain about. I also see how it should work in your setup as well.
>
> Yes, I know that I could do things better. But in my defence, install
> rpaths are not default (there must be reason for it?) in cmake and other
> projects do not seem to enable it so extensively. 

Well, we don't have that many options how to set RPATHs:
1) make them empty

2) have cmake set them automatically to all dirs which were used for 
linking -> gives automatically all necessary RPATHs to the executables and 
libraries

3) set them manually to all directories which are required -> too much manual 
work, does not work for KDE, we have too many dependencies. Typical KDE 
developers are not "complete" project maintainers, which (have to) care about 
everything, from coding to releasing etc. This includes knowing the details 
about the build system. So the manual option is IMO no valid option for KDE.

> So it more looks like KDE
> problem rather than cmake problem. Though cmake could be smarter in this
> case.

I would appreciate a lot of you could file this in the cmake bug tracker. You 
know what you want, so I don't have to be a proxy for that:
http://public.kitware.com/Bug

> > > 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.
>
> I'm satisfied by this. The quick question was if it had been implemented in
> the rest of KDE trunk / kdesupport trunk as well. That's because I don't
> follow trunk development but probably will only get to it when 4.5 is about
> go out. Your last mail seemed like you somewhat didn't want to ack. that
> there was a problem and offered CMAKE_SKIP_RPATH as a solution.

Yes, because I was not really aware of it.
I'm still confused after your email.
Above you write:
"I believe that cmake defaults ( no install rpath ) meet debian's and majority 
of distros needs completely."
but then again you say that CMAKE_SKIP_RPATH is not an acceptable solution.

Can you please explain ?

Alex