On Friday 13 November 2015 10:30:43 Chris Cannam wrote: > > On Fri, Nov 13, 2015, at 10:14 AM, David Faure wrote: > > I have never seen unittests being fully part of the one big monolithic > > application and ran with a command-line argument... but indeed > > that would be one possibility I suppose. > > I was thinking more that you have a separate main.o but the other > objects are the same. There's no particular advantage to that, I just > meant that it's all simply object files and executables -- via libraries > is only one of the ways to get there. An unimportant detail at this > point anyway.
OK, I see what you mean. Manual Makefile writing would lead to this kind of idea indeed ;) Static libs are just a convenient way to handle "a bunch of .o files", as far as build systems are concerned. > > Anyway I like incremental changes so my plan is > > 1) build with cmake exactly what is being built now > > 2) make one big static library with everything except main() > > 3) write a first unit test > > Sounds very reasonable to me. > > Rosegarden has actually had both a multiple-shared-libraries build > system and a small number of unit tests in the past. The former was a > bit of a pain for reasons Michael touched on, the latter eventually lost > all compatibility with the code around them as nobody ever ran them. For > my part, I didn't really start writing unit tests at all until after the > point I stopped working on RG (sorry). If it's practical to have them > run during every build, that's generally preferable At least I strongly encourage that all unittests should be *built* during every build. Otherwise they get broken too fast as you noticed. Running can take a bit more time and should definitely be a separate operation (`make test`). Ideally you'd also have a CI system that runs them regularly and reports regressions, but as long as you're in sourceforge I suppose that's not going to be available. One could set up a jenkins separately, but that's a lot of work compared to using an existing CI infrastructure... Well, let's come back to the svn vs git discussion later, one revolution at a time ;) > , which means > > > I suppose the best of both worlds would be supporting two modes: > > * without unit tests enabled, one static lib, one executable > > * with unit tests enabled, one shared lib, N executables > > could be a good idea, with the first mode being the default installation > mode. Unless that just proves too confusing. My fear is not confusion, but that even developers will use that mode, and therefore the unittests will never get even built. (I'm pretty sure that we can't just toggle this based on "release" vs "debug" because surely you have users using "debug" ? Those same "advanced" users to whom you want to be able to ask to re-test with a previous uninstalled build etc.) > fwiw (which is very little) on other Qt projects these days I generally > use both the Qt test library and Qt Creator (at least on Windows; on > Linux it's Emacs of course, and OS/X I try to avoid editing anything on) I used to be an (X)Emacs user, until OpenSUSE broke it, at which point I took the opportunity to re-evaluate and switched to QtCreator, which has the advantage of being the same on all three desktop OSes. -- 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
