setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

[Alexander Neundorf]

On Thursday 10 May 2012, David Faure wrote:
> 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

In KDE4 kdelibs all executables have always been built into 
${CMAKE_BINARY_DIR}/bin/, and nobody complained. Or am I mixing something up 
completely ?

> make && ./kurltest
> or make kurltest/fast && ./kurltest
> rather than
> make && ../../bin/kurltest

You could do
make && bin/kurltest

or you could use ctest directly:

make && ctest -R kurltest

then you don't have to care where the executable actually is.
After the -R you can list a regular expression, and all matching tests will be 
executed.
To see the output, add -V and maybe -VV:
make && ctest -V -VV -R kurl

> And why is it OK for Qt autotests (to be built in the directory containing
> the sources), but not for kde frameworks autotests?

I don't know, and I don't care.

In KDE4, we additionally generated wrapper scripts, which set up PATH and 
(DY)LD_LIBRARY_PATH accordingly.
Now we don't do that anymore.
So for Windows the dlls and the exes have to go into the same directory.

I'd also prefer to avoid
if(WIN32)
  set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)
endif()

and use instead simply

set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)

It also works, no problems under any OS, and we have a consistent layout :-)

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