David Kastrup <[email protected]> writes: >> 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.
To put some more perspective to this: I am now in the situation of having to maintain a separate 2.16 stable branch. In the course of this, I expect a somewhat regular necessity backporting bug fixing changes. This backporting will become quite harder with larger source reorganisations. If there is going to be a double file standard, it would be preferable to have the shim called something different and retain the old file name for the guile v2 code. BUT. I don't buy in the parallel file story really. I think that the bulk of the code should likely be identical, and maintaining two copies of it is a recipe for bit rot. So I'd prefer to go either with localized conditional code, or just Guilev2 wholesale. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
