Re: [CMake] another RPATH problem

2006-06-16 Thread Brad King
Alexander Neundorf wrote: It is now in CVS and it will be in 2.4.3, and if CMAKE_PATCH_VERSION is not set you can assume an earlier version. This means CMAKE_PATCH_VERSION will work in 2.4.3 ? Yes. -Brad ___ CMake mailing list CMake@cmake.org http:

Re: [CMake] another RPATH problem

2006-06-15 Thread Brad King
Alexander Neundorf wrote: Would it be possible to apply it also to the 2.4 branch, but maybe keep it undocumented until it has proven its usefulness ? I can test it on my machine, but it can get wider testing (KDE) only if it goes into the 2.4 branch. We'll merge it to the 2.4 branch for the

Re: Re: [CMake] another RPATH problem

2006-06-15 Thread Alexander Neundorf
Hi, Von: Brad King <[EMAIL PROTECTED]> > Alexander Neundorf wrote: > > Would it be possible to apply it also to the 2.4 branch, but maybe > > keep it undocumented until it has proven its usefulness ? > > I can test it on my machine, but it can get wider testing (KDE) only > > if it goes into the

Re: Re: [CMake] another RPATH problem

2006-06-15 Thread Alexander Neundorf
Hi, Von: Brad King <[EMAIL PROTECTED]> > Alexander Neundorf wrote: > > 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

Re: [CMake] another RPATH problem

2006-06-15 Thread Brad King
Alexander Neundorf wrote: 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. Okay, I've impl

Re: Re: [CMake] another RPATH problem

2006-06-14 Thread Alexander Neundorf
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

Re: [CMake] another RPATH problem

2006-06-12 Thread Brad King
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

Re: [CMake] another RPATH problem

2006-06-10 Thread Alexander Neundorf
> Von: Alexander Neundorf <[EMAIL PROTECTED]> > Hi, > ... > But I see a third option which sounds quite compelling to me. Should be "quite promising" Alex -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___

[CMake] another RPATH problem

2006-06-10 Thread Alexander Neundorf
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/l