Re: Time to fork a guile-2 branch?

[David Kastrup]

Ian Hulin <address@hidden> 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