Hello guys, I just subscribed, so I'm replying by pasting text from the archives.
On 11/12/2015 04:38 AM, Chris Cannam wrote: > The only thing that puzzles me is -- why is it necessary to switch build > systems just to add unit tests? A test is just a small program, it > shouldn't be hard to build. This isn't exactly true. A unit test is not just a standalone program, it uses classes from the application. So the application can no longer be a single monolith, it needs to provide libraries that the unittests can link to. Of course in very simple case (unittesting a standalone parser in a single file with no dependencies towards the rest of the program), a quick hack is possible instead, compiling the code-under-test (e.g. the parser) into the unittest. But in general, things depend on other things, so you need libs for unittests to even be possible. This gives two possibilities: static libs and shared libs. I would strongly recommend shared libs, they make the "change code ; build ; test" cycle faster because there's no need to relink the executables (the app and the unittests) so that they use the new static library. Incidentally this change would also fix the "gigantic link step", although that wasn't my intention originally :-) I see the point about long-term maintenance, I'll try to document the thing while writing it. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ------------------------------------------------------------------------------ _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
