lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Time to fork a guile-2 branch?


From: David Kastrup
Subject: Re: Time to fork a guile-2 branch?
Date: Mon, 13 Aug 2012 10:26:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

David Kastrup <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]