On Thursday 10 May 2012 22:53:01 Alexander Neundorf wrote:
> 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/.

No, unit tests have always been built into the current directory.
We are talking about tests here, not about anything else!
Please look in kdelibs/kdecore/tests and every other dir.

> You could do
> make && bin/kurltest

That builds everything first, which is much slower than just building kurltest.

> then you don't have to care where the executable actually is.

And when you need to run it in valgrind or gdb? Sorry but you do need to care 
where the executable is.

> > 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.

Not such a diplomatic answer...

> In KDE4, we additionally generated wrapper scripts, which set up PATH and
> (DY)LD_LIBRARY_PATH accordingly.

Yep I liked that...

> Now we don't do that anymore.
> So for Windows the dlls and the exes have to go into the same directory.

And how will the libs be found on Unix, given that they are under lib/ and not 
bin/?

Putting all executables in bin doesn't remove the need for wrapper scripts, on 
unix.

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

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to