Ian Hulin <[email protected]> writes: > Dear all, (especially David and Graham) > Contrary to all indications, I have actually been slowly (very slowly) > chugging away on this, developing on my netbook. > > In order to achieve this, we'll need produce a series of patches. The > criterion for accepting the patch for guile V1 systems would, as ever, > be - do no harm, run the regtests without change. > > 1. Add conditionally compiled/executed code in main.cc where necessary > for using differing calls for guile V1 and guile V2, the guile 1 > branches remaining the same. This is now mostly complete, subject to > changes required by steps 2 and 3.
It is probably safe to assume that switching at runtime is not feasible because of different library APIs. > 2. Add new lily-guile2.scm, this is lily.scm re-written to use new > (include-from-path) guile macro instead of loading component files. > The current code in lily.scm is copied unchanged to lily-guile1.scm > and the lily.scm becomes a shim with > (cond-expand (guile-2 > (include-from-path "lily-guile2.scm")) > (guile > (load-from-path "lily-guile1.scm"))) If the move is done unchanged in one commit, git should likely be able to figure it out. > 3. Where there are significant changes to component .scm files for > guile V2, these will also be converted into a shim similar to lily.scm > and will have <file>-guile-1.scm and <file>-guile-2.scm files > produced. The more material we can reorganise to work without that split, the better: maintaining parallel material is not really reliable. Personally, I am almost in favor of a rather hard cut where we switch from Guilev1 to Guilev2. The problem with that is that such a step cannot really be prepared separately since it would likely get code outdated: we had that problem previously. Most direct would be a hard cut: exchange the Guile version, and get everybody working furiously until LilyPond works again. > Given that these patches will be quite extensive, is now a good time > to set up a guile-2 branch in git, forking off from the start of the > V2.17.0 development? If the idea is to keep Guilev1 and Guilev2 working in parallel, the only reason to make a fork/branch would be using it to develop the best porting strategy, and once that is settled, start over from scratch on master for real. And/or do extensive rebasing to bring the material into logical shape. While restarting from scratch after getting hands-on experience tends to lead to the cleanest solutions, I doubt that this is what you have in mind. > If the answer is yes, I may need some hand-holding/support to make > sure I don't do any damage to the main git repository. > > Sorry I won't be able to make the developer's meeting at Waltrop, but > I'll be on a flute summer course in France between 22 and 30 August. Pity. At least you will be having fun with music. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
