setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

[David Faure]

On Thursday 10 May 2012 11:15:57 Patrick Spendrin wrote:
> Am 10.05.2012 10:45, schrieb David Faure:
> > On Thursday 10 May 2012 10:36:20 Patrick Spendrin wrote:
> >>> set(EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR})
> >> 
> >> Yes, the EXECUTABLE_OUTPUT_PATH should be set per project into the
> >> project binary_dir\bin
> > 
> > As a linux developer, I don't like this. I want to be able to do
> > make && ./kurltest
> > or make kurltest/fast && ./kurltest
> > rather than
> > make && ../../bin/kurltest
> 
> Well, I don't want to impose this on Linux, I would even think
> restricting this to windows is ok.

Even on Windows I like to have everything in one place, but yes, it requires 
setting PATH. No big deal, though... We're talking about programs run by 
developers, who have to set PATH anyway (to point to Qt among other things).

> One other solution I could think of is to link the test executables into
> that directory (so that ./kurltest works for you), but I am not sure how
> hard that would be.

Aeh? You lost me. Linking (creating) the test executables into the current 
directory, is exactly what this whole discussion is about...

> > And why is it OK for Qt autotests (to be built in the directory containing
> > the sources), but not for kde frameworks autotests?
> 
> The problem will exist everywhere, except if tests are statically linked
> to the tested code.

And the solution will exist everywhere: exporting PATH (Windows) or 
LD_LIBRARY_PATH (Unixes).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5