apaku at gmx.de
Thu Jul 17 13:52:57 UTC 2008
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
> 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
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.
A tall, dark stranger will have more fun than you.
More information about the KDevelop-devel