EXECUTABLE_OUTPUT_PATH for tests

David Faure faure at kde.org
Sat Sep 22 21:44:20 CEST 2007


On Friday 21 September 2007, Andreas Pakulat wrote:
> On 20.09.07 18:43:25, Alexander Neundorf wrote:
> > 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.
> 
> Ok, that should be advertised, especially the ctest -V -R <test> method
> to see the output from the tests so one knows which tests fail.

Good tips, but really, ./kservicetest is just much simpler. It allows to also do
gdb ./kservicetest and valgrind ./kservicetest, so it needs to stay this way.

> > 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 ?
> 
> I don't see any problem with putting the EXECUTABLE_OUTPUT_PATH back
> into the CMake files and also setting the target property. I never said
> that and I certainly never meant to imply that.

Adding the property is a good idea of course.
Putting the variable back into the cmake files: well, if it makes you (Alex) sleep better,
go ahead. Please realize though that it will re-create some inconsistency in the
various tests dirs around (some people will forget it), so I preferred the idea of
leaving it in the macro until cmake-2.6, but I will sleep OK if you move it back
to the cmake files :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


More information about the Kde-buildsystem mailing list