New dependency for kdelibs and kdebase: dbusmenu-qt

[Modestas Vainius]

Hello,

On šeštadienis 08 Gegužė 2010 00:11:07 Alexander Neundorf wrote:
> Ok, now I actually tested it.
> Please try the attached example yourself.
> It links an executable with one library in /lib/, one in /usr/lib/, one
> in /usr/local/lib/, and one in /opt/kdelibs/lib/, with
> INSTALL_RPATH_USE_LINK_PATH enabled.
> 
> Resulting RPATHS in the installed executable:
> cmake 2.4.5: /opt/kdelibs/lib:/usr/local/lib:/lib
> cmake 2.6.2: /opt/kdelibs/lib:/usr/local/lib
> cmake 2.8.1: /opt/kdelibs/lib:/usr/local/lib
> 
> cmake 2.8.1 with /usr/local/lib added to
> CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES in
> Modules/Platform/UnixPath.cmake: /opt/kdelibs/lib
> 
> So the directories listed in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES are
> not added to the RPATH by cmake.

Well ok, so cmake is smart enough for INSTALL_RPATH_USE_LINK_PATH. Apparently, 
INSTALL_RPATH_USE_LINK_PATH is ok to enabled by default.

But the problem is that KDE sets CMAKE_INSTALL_RPATH / INSTALL_RPATH manually 
in numerous places as well. For example, the following propagates this bad 
practise to all KDE applications:

http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/FindKDE4Internal.cmake?view=markup

line 998.

So those CMAKE_INSTALL_RPATH are what I had to patch out mostly. Basically, 
grepping for CMAKE_INSTALL_RPATH and INSTALL_RPATH target property would 
reveal all evil cases. However, I have a feeling they are redundant even in 
your setup when INSTALL_RPATH_USE_LINK_PATH is in effect?

-- 
Modestas Vainius <modestas at vainius.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100508/7bc03b19/attachment.sig>