On 29.06.10 23:21:10, Alexander Neundorf wrote: > On Monday 28 June 2010, Andreas Pakulat wrote: > > On 28.06.10 08:44:35, Brad King wrote: > > > Andreas Pakulat wrote: > > > > On 26.06.10 13:26:29, Andreas Pakulat wrote: > > > >> Ping? Any further ideas on this? Could someone at least point me to > > > >> the source code in cmake that decides wether to add RPATH_REMOVE or > > > >> RPATH_REPLACE to the cmake_install.cmake file? > > > > > > Look at "cmInstallTargetGenerator::AddChrpathPatchRule". Its job is > > > to generate the install-time script to fix up the RPATH in the installed > > > binary. The default is *no* RPATH, unless the INSTALL_RPATH target > > > property is set: > > > > > > > > > http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:INSTALL_RPAT > > >H > > > > > > Elsewhere in this thread (at least on the kde list) you mention this > > > seems to be working for some targets and not others. Look for where > > > the INSTALL_RPATH gets set on the targets where it is working. > > > > Let me clarify, I have two projects: kdevplatform and kdevelop. Both > > have multiple targets, in particular: > > > > kdevplatform > > - libfoo > > - libbar > > - fooplugin > > - barplugin > > > > kdevelop > > - anotherplugin > > - someexe > > > > Now libbar links against libfoo, fooplugin and barplugin both link again > > libfoo and libbar. someexe and anotherplugin too. > > > > When I now build kdevplatform I get "Removed runtime path" for each > > installed library/plugin. Whereas doing the same in kdevelop shows "Set > > runtime path of", i.e. the rpath of all binaries are adjusted to use the > > install dir. > > > > Both projects are being installed to the same prefix, namely > > $HOME/kdevelop using -DCMAKE_INSTALL_PREFIX. > > The thing here is that e.g. barplugin in the build tree automatically gets > the > RPATH inside the buildtree, e.g. to libbar. But if it doesn't link to > anything outside the buildtree, the install RPATH will be empty. > If libbar would be already installed e.g. in /opt/kdev/lib/, and libbar would > be linked against it, and CMAKE_INSTALL_RPATH_USE_LINK_PATH is > enabled, /opt/kdev/lib/ would end up in the install RPATH. > > But if libbar is part of the same project (as barplugin) this is not the case. > > One could argue whether it would make sense to automatically add the install > directory of libraries of the same project to the install RPATH if > CMAKE_INSTALL_RPATH_USE_LINK_PATH is enabled. > But currently that's not the case, so the lib install dir has to be added > manually to the INSTALL_RPATH if necessary (see code below).
IMHO that would make sense indeed, building a plugin in the same project is not really different from building it in a separate project (from a users point of view). > > > 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. Andreas -- You will always get the greatest recognition for the job you least like. _______________________________________________ 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