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