On Wednesday 30 June 2010, Modestas Vainius wrote: > Hello, > > On trečiadienis 30 Birželis 2010 11:33:07 Andreas Pakulat wrote: > > > > > As I said above it won't affect the install tree. See the > > > > > INSTALL_RPATH target property. > > > > > > > > That property is not set (and the global variable > > > > CMAKE_INSTALL_RPATH) is empty too, nonetheless one project gets rpath > > > > info set in the installed plugins/executable the other one doesn't. > > > > > > It shouldn't be empty, it is set in FindKDE4Internal.cmake around line > > 1000: > > Ah, apparently thats also been patched out by Debian, didn't see that > > when comparing with the original file... > > > > Re-adding that line does work. > > Yes, I went to extremes a bit disregarding apparent expectations of users > installing from source to different prefix. Softened approach (backport > from trunk) has not made to the archive yet. > > However, I still think that KDElibs should stick to cmake defaults with > respect to RPATH settings giving users freedom to use RPATH or > LD_LIBRARY_PATH or /etc/ld.so.conf.d/. CMAKE*RPATH* look like candidates > for users to set rather than projects themselves, don't they?
You can disable RPATH completely via CMAKE_SKIP_RPATH, which is a cache variable, if it is not disabled, IMO the combination which is set now is the one which makes it all work correctly. I don't think somebody would actually want to set this to something different. We could still make these variables cache variables, then it would be possible to change them. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
