[Top][All Lists]
[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
Re: Time to fork a guile-2 branch?, Reinhold Kainhofer, 2012/08/13