KDE/kdevplatform/veritas

[Andreas Pakulat]

On 17.07.08 13:33:05, Manuel Breugelmans wrote:
> On Thursday 17 July 2008 13:02:19 Andreas Pakulat wrote:
> > > So invoking `make && make buildtests' will not compile. Proper
> > > solution is probably something with CMAKE_BUILD_TYPE.
> >
> > No, proper solution is to include the .cpp files that you want to test
> > directly, or build another library thats not installed but just used for
> > the tests (which then uses default visibility).
> >
> > Using the build-type is not the proper way of deciding wether tests
> > should be built or not.
> >
> 
> Hmm I don't quite follow you on that ;)
> 
> How is the problem here (pass an extra visibility flag) to make stuff testable 
> different from making your code debuggable (pass an extra -g flag)? In my book 
> it isn't. The debug thingy is handled with CMAKE_BUILD_TYPE through 
> RelWithDebInfo and friends.

But there is no RelWithTests or similar - at least not per default
(which means we'd be the only ones having that and nobody knows about
this). Tests should be buildable with any buildtype and I don't like the
idea _at all_ of having a library with uneeded symbols exported. Note
that distributions build KDE4 with RelWithDebInfo to get debug symbols
out of it (AFAIK), so you can't use that buildtype for testing, only the
debug.

> Anyway I'll take a dive into cmake doc's later to check if this is user 
> extensable. Compiling twice is not an option really ... way too slow (would 
> you always compile twice to get debug symbols? Not me nor anyone I know.).

Well, not everyone is building tests anyway and  one can easily opt not
building them while hacking on some code. So I don't really see that
much of a problem. Besides: I'm actually thinking it might make sense
to move the runner-gui-code elsewhere (into the project treeview), in
which case you can have a fully-exporting library there which is easily
testable.

Its really a shame that CMake doesn't expose the .o files, if it did we
could just re-use those for building the tests without recompilation...

> Related to this: I will need an extra build configuration for the third part of 
> my SOC: coverage. Gcov needs some linker flags to be added. It would be nice if 
> this is somehow abstracted away for the user.

Hmm, this could be done by extending the buildtools API with something
like enableCoverage() and then issue a rebuild of the target/project...
Or maybe we just expose a way to set Linker and Compiler flags via the
buildsystem API as other coverage systems (are there any?) might need
other flags... I suggest we talk about that in a new thread once you're
ready to start with it.

Andreas

-- 
A tall, dark stranger will have more fun than you.