EXECUTABLE_OUTPUT_PATH for tests
apaku at gmx.de
Thu Sep 20 02:51:06 CEST 2007
On 19.09.07 19:21:46, Alexander Neundorf wrote:
> On Wednesday 19 September 2007 18:55, Andreas Pakulat wrote:
> > On 19.09.07 18:40:16, Alexander Neundorf wrote:
> > > Imagine this cmake code:
> > >
> > > add_executable(foo main.cpp)
> > > add_executable(bar bar.c)
> > Tests in kdelibs, kdepimlibs and other modules are in a separate
> > subdirectory with a separate CMakeLists.txt. Nearly all tests I
> > converted when adding these two macros were setting
> > EXECUTABLE_OUTPUT_PATH in that CMakeLists.txt.
> I think this is better, it makes obvious what is going on.
> This is about readability and long term maintainability.
> Reading SET(EXECUTABLE_OUTPUT_PATH wherever/) makes it very clear what
> happens, without requiring additional knowledge.
But I also saw quite some test-subdirs where this was forgotten, which
is why I added it to the macros.
> It is just one simple line of code. This is somewhat similar to many of the
> changes in Qt4, where all-in-one-line ctors with many arguments were replaced
> by a simple ctor and multiple simple do-one-obvious-thing functions.
Well, except that with Qt4 if you forget a "setBold()" call you'll
instantly see it, whereas you don't instantly notice where binaries end
up until you try to find them.
> What we have now is a hidden side effect by setting a (more or less) global
> variable in some seemingly unrelated function.
Well, then we should document that side-effect in the "API" doc for the
macros (and thus also on techbase).
> > This is something that at least kdelibs developers want, putting the
> > tests into the current directory as that way you can easily check bin/
> > to see which binaries are going to be installed.
> I don't see the significant value in this and it is only partly true. With the
> example above also foo and bar wouldn't appear in bin/, while they can have
> install rules.
As I said already, tests are usually in a separate subdir without "real"
installed binaries and thus this doesn't matter.
> If it helps we could automatically put a "test_" prefix in front/at the end of
> all test executables to make this obvious.
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.
Anyway, so far we're only 2 people who disagree, I'd say we need a 3rd
Alimony and bribes will engage a large share of your wealth.
More information about the Kde-buildsystem