On Friday 13 November 2015 15:00:01 David Faure wrote: > (I assume the off-list reply was not intentional?) > > On Friday 13 November 2015 13:37:10 Dr Nicholas J Bailey wrote: > > Sorry, David, I wasn't being clear. I meant first build several little > > static libraries, then run the unit tests against them, linking only the > > necessary ones. Then link all the static libraries to the main > > executable. > > I see what you mean. But "small" assumes that the dependencies between > the classes aren't a big bowl of spaghetti... I don't know yet if they are > or not, we'll see. There's the big question, right there :)
In the case of the other project I mentioned, it's a matrix mixer (p ins -> q outs, a mixer pot for each possible intersection, and you can assign 1 or more pots to a MIDI controller surface). Here's the link line, in its entirity: g++ -o jackmix/jackmix jackmix/main.o jackmix/mainwindow.o -Lbackend - Llibelements -Llibmatrix -Llibgui -Llibqlash -Llibcore -Llibcontrol - lQt5Widgets -ljackmix_backend -ljackmix_mixingelements -ljackmix_core - ljackmix_gui -ljackmix_mixingmatrix -lqlash -ljackmix_control -lasound -ljack -llash -lQt5Gui -lQt5Xml -lQt5Core of which 7 are "convenience" libraries (count the -Ls). But there aren't very many c++ files: nick@ariel:~/Packages/jackmix$ find . -name \*.cpp | wc -l 25 (that includes the tests). But Arnold (the main author of the other project) started from the ground up with a "module"-level idea, so the archive files already had a sort of independence. I can see how this may or may not work for Rosegarden. > > I think I wasn't being clear either. I should say "auto tests" rather than > "unit tests", because I'm thinking of both unit tests (for one class) and > higher-level integration tests (like "load this rg file, export to > lilypond, check output against baseline, and/or run lilypond to ensure it > compiles"). Could still work. You might have a greater or lesser number of archives linked depending on how complex the particular test was. I guess you'd have to try and see if this just got out of hand and became a nightmare to maintain or not. We ended up loving it, but in a much smaller and less complex project. > > And for this to be possible, surely I will need to drag in a large number of > classes (maybe not the GUI code, but that assumes a clean core/gui > separation, don't know if that's the case here, at least the buildsystem > never enforced it). > > Class-level unit tests are very useful for some things, but sometimes a > class redesign means most of the test doesn't apply anymore. On the other > hand a high-level integration test will always make sense, unless one day > you decide not to use lilypond at all anymore ;). Absolutely right. > > In conclusion, I don't expect to be able to just use "small static libs", > unfortunately, at least not without much more effort like refactorings and > redesigns, speaking from experience with starting from a monolithic app. > But maybe I'm wrong, we'll see ;) When maintaining or adding to what others have written, I find it's always important to respect their original style and design decisions. Certainly the many-small-archives approach might be impossible. But it worked very well for us. When we did a bit of work on Rosegarden a while back (it was the pitch tracker), we found it very easy to work with the code base. Then the qt4 port happened, and we weren't using many of the facilities we added very much at that time, so the current functionality is a shadow of its first incarnation. That's exactly what you're talking about when it comes to tests becoming inappropriate. Soon, we might want to get back on it again. Maybe when the qt5 port happens :) We have a new generation of microtonal performers who may be needing an accompanist with a built-in rehearsal aid. If/when the tuple-handling suddenly improves, we'd be very happy chappies. Much of the music our composer writes has lots of tuples (and not just "easy" ones). Since the last batch of performers "got their ear in" at the non-standard temperaments, they stopped using the pitch tracker and we went over to just writing lilypond then using its microtonal extensions to produce standard MIDI accompaniment files. But that's another story. > > PS: the cmake buildsystem is almost ready, I just linked rosegarden > successfully. Excellent! That was quick work! Nick/. ------------------------------------------------------------------------------ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
