setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

[Alexander Neundorf]

On Friday 11 May 2012, David Faure wrote:
> On Thursday 10 May 2012 23:44:31 Stephen Kelly wrote:
...
> > http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/
> 
> Thanks. So the problem is that the mere presence of RUNPATH, disables the
> (deprecated) RPATH, and therefore $LD_LIBRARY_PATH is used, i.e. the
> installed libs are picked up.

Yes.
http://www.cmake.org/Wiki/CMake_RPATH_handling

> For a developer working on a given framework that's not a huge deal, but
> for simply running "make ; make test" in all frameworks, this is an issue.
> This is exactly what the wrapper scripts were solving in kdelibs-4...

They were mainly intended for the CMAKE_SKIP_RPATH=TRUE case.
I can't remember that I got any feedback on them, which makes me think that 
the wrapper scripts were mostly unknown.
Creating those in kde4_add_executable() was no problem, but since one of the 
goals is to use plain cmake commands, i.e. add_executable(), this cannot be 
done automatically anymore.
 
> Surely we must not be the only cmake users who make shared libs and
> unittests for these libs -- and the tests are supposed to pick up the
> uninstalled libs. Can cmake get the "wrapper scripts" feature? Or is there
> a RPATH setting that would fit better for this?

We enable RUNPATH explicitely, it's not cmake's fault.
If we would not add --enable-new-dtags, everything would just work.

IMO RPATH and RUNPATH are just two different behaviours, which one is 
considered "better" is IMO subjective.
(IOW I haven't understood why RUNPATH is claimed to be The Right Thing).

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120511/ad63515e/attachment-0001.html>