[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: EXECUTABLE_OUTPUT_PATH for tests
From:       Alexander Neundorf <neundorf () kde ! org>
Date:       2007-09-20 22:43:25
Message-ID: 200709201843.25232.neundorf () kde ! org
[Download RAW message or body]

On Thursday 20 September 2007 04:04, David Faure wrote:
> On Thursday 20 September 2007, Andreas Pakulat wrote:
> > On 19.09.07 21:31:39, Alexander Neundorf wrote:
> > > On Wednesday 19 September 2007 20:51, Andreas Pakulat wrote:
> > > ...
> > >
> > > > Well, I also quite often execute tests manually, especially QtTest
> > > > based ones, because that way I can see their full output. And if I'm
> > > > in <builddir>/myplugin/ or <builddir>/myplugin/test its much easier
> > > > to run test/mytest (or ./mytest) then ../../bin/test_mytest.
> > >
> > > I didn't argue that it doesn't make any sense to have the test
> > > executables in the current dir, but that while it makes some sense OTOH
> > > it creates an ugly side effect.
> > >
> > > > Anyway, so far we're only 2 people who disagree, I'd say we need a
> > > > 3rd opinion :)
> > >
> > > Ok, it is possible per target with cmake cvs HEAD:
> > >
> > > set_target_properties(mytest PROPERTIES RUNTIME_OUTPUT_DIRECTORY
> > > wherever)
> > >
> > > If we put this in the macros for the test executables, developers who
> > > really want that can use cmake cvs (which will become 2.6.0). I use it
> > > every day, it's stable.
> >
> > Well, I think our devs got more important stuff to do than trying out
> > the latest cmake ;) So when CMake 2.6 is released and used by KDE4 then

They don't have to :-)
OTOH it would be good if some would use current cvs so we can detect 
breakages. Ideally we should have a nightly build of current kde with current 
cmake (additionally to the nightly build of kdelibs with cmake 2.4.5 which we 
don't have).

> > this seems to be the best solution.
>
> I'm the one who added the set(...) in every CMakeLists.txt but I didn't
> move it to the macro. So: we all agree that setting the output dir is good,
> and we all agree that doing it as a directory-wide side-effect is bad,
> we only have to agree on the fix. I'm with Andreas: *once* KDE requires
> cmake-2.6, let's fix the macro to use set_target_properties. This way we
> have no immediate regression and we fix the bug when we can fix it, i.e.
> when we require 2.6.

I set EXECUTABLE_OUTPUT_PATH at all initially beginning last year because I 
set LIBRARY_OUTPUT_PATH. A common LIBRARY_OUTPUT_PATH makes running the 
uninstalled executables easier (RPATH, Windows, etc.). And it is one way to 
make it easier to determine where created executables will be created (there 
are better ways I learned).

Actually, what about Windows ? 
Doesn't not using EXECUTABLE_OUTPUT_PATH make running the test apps harder 
(because they don't find their dlls) ?

We could also completely ignore EXECUTABLE_OUTPUT_PATH (except under Windows) 
and have the executables always created in their directory.
Opinions ?

Two more notes:
to run tests (i.e. added via ADD_TEST) it is not necessary to know where the 
executable is located. You can run the tests via ctest:
$ ctest        <- runs all tests in this dir and below
$ ctest -R kio <- runs all tests whose name match .*kio.*
There are more options like this.

Another way to make it easier to run them manually would also be just to have 
a shell in EXECUTABLE_OUTPUT_PATH always open and run the tests always 
manually there.

Yes, we all agree that setting the output path makes some sense and that the 
side effect is bad.
I understand you this way that we remove the side effect now and put the 
EXECUTABLE_OUTPUT_PATH in the cmake files back -> no side effect, tests are 
in the current dir, everybody sees what's going on.

But where do you see a problem with putting the SET_TARGET_PROPERTIES() call 
which sets the individual output path in the macro now ?
For everybody who uses cmake 2.4.x it will be ignored, for everybody else it 
will work.


Bye
Alex

_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
[prev in list] [next in list] [prev in thread] [next in thread]