On 30.06.10 12:07:11, 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?
Except that the occassional user of $foo-project has no clue about these and would have to consult the cmake manpage. And those users also shouldn't be forced to install into /usr/local either IMHO. I might agree about not doing this at the kdelibs level, but then it would've to be duplicated on each module/app... Andreas -- You will wish you hadn't. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
