Hi,

Von: Brad King <[EMAIL PROTECTED]>

> Alexander Neundorf wrote:
> > Hi,
> > 
> > although cmake now supports RPATH very flexible, we still have a
> problem.
> > The install RPATH has to be constructed manually. In KDE we set it to
> the Qt libdir, the KDE libdir and the install libdir.
> > Now the problem is, what to do if the app links to a library which has
> been found (e.g. /usr/lib/dbus/lib/libdbus-1.so ) but which isn't in the
> LD_LIBRARY_PATH ?
> > Requiring every developer to adjust the INSTALL_RPATH manually for every
> lib he links to doesn't seem like a viable solution.
> > Another option is just to require that (DY)LD_LIBRARY_PATH is set up
> correctly.
> > 
> > But I see a third option which sounds quite compelling to me.
> > When linking and when relinking during install, cmake adds all required
> link dirs using -L ... to the command line.
> > Shouldn't it be possible to use the same set of link dirs also for the
> RPATH ?
> > This would solve all our problems I think.
> 
> It will be hard to separate build-tree linking dirs from install-tree 
> linking dirs.  Consider a pair of projects A and B.  I build A, and then 
> build B using the build tree of A to link its libraries.  Then I install 
> both.  Now B's rpath will point at the build tree of A instead of its 
> install location.

Two independent projects as in two independent source trees and then one of 
them is built against the uninstalled other ?
E.g. like building kdebase against an uninstalled kdelibs ?
The cmake FindFoo.cmake modules won't find the uninstalled libs, so manual 
adjustment is required. 
If in this case something strange happens if the (not yet existant) option to 
use the "external" RPATH also for installing is enabled, then it's acceptable 
I'd say.
 
> Every project will have its own policy of RPATH/no-rpath/etc.  I think 
> the best solution is to have the Find*.cmake scripts provide a 
> FOO_RUNTIME_LIBRARY_DIR variable along with FOO_LIBRARY and 
> FOO_INCLUDE_DIR.  This directory could then be used for the RPATH of 
> something that links to FOO.  

I think extracting the directory part from the full name of the library would 
do the job too.
Still this would mean that every developer has to deal with this if he adds 
another library.
And average developers (like me until maybe three months ago) often don't 
really know how to deal best with RPATH stuff.

> Also on Windows it would provide the 
> location of foo.dll which may be different from that of the foo.lib 
> being linked.

Attached you can find a patch against current cvs which adds an option with the 
nice name CMAKE_USE_EXTERNAL_RPATH_FOR_INSTALL, which if enabled has the effect 
that lib dirs which are outside the build- and source tree are added to the 
install RPATH.

Please take it into consideration, IMO it might be useful.

Bye
Alex

-- 


Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
Index: cmLocalGenerator.cxx
===================================================================
RCS file: /cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v
retrieving revision 1.139
diff -b -u -p -r1.139 cmLocalGenerator.cxx
--- cmLocalGenerator.cxx	14 Jun 2006 16:28:30 -0000	1.139
+++ cmLocalGenerator.cxx	14 Jun 2006 20:42:10 -0000
@@ -1418,6 +1418,8 @@ void cmLocalGenerator::OutputLinkLibrari
     outputRuntime && tgt.HaveInstallTreeRPATH() && linking_for_install;
   bool use_build_rpath =
     outputRuntime && tgt.HaveBuildTreeRPATH() && !linking_for_install;
+  bool use_external_rpath_for_install = 
+    outputRuntime && linking_for_install && this->Makefile->IsOn("CMAKE_USE_EXTERNAL_RPATH_FOR_INSTALL");
 
   // Construct the RPATH.
   std::vector<std::string> runtimeDirs;
@@ -1454,7 +1456,15 @@ void cmLocalGenerator::OutputLinkLibrari
          && libDir->find("${") == std::string::npos)
         {
         linkLibs += libPathFlag;
-        if(use_build_rpath)
+
+
+        if(use_build_rpath || (use_external_rpath_for_install &&
+           // Use this directory only for the install RPATH if it is not a subdirectory
+           // of the top-level source or binary tree.
+           !(cmSystemTools::ComparePath(fullLibPath.c_str(), topSourceDir) ||
+             cmSystemTools::ComparePath(fullLibPath.c_str(), topBinaryDir) ||
+             cmSystemTools::IsSubDirectory(fullLibPath.c_str(), topSourceDir) ||
+             cmSystemTools::IsSubDirectory(fullLibPath.c_str(), topBinaryDir))))
           {
           runtimeDirs.push_back( fullLibPath );
           }
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to