Re: Time to fork a guile-2 branch?

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Mon, Aug 13, 2012 at 09:38:15AM +0200, David Kastrup wrote:
>> > 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.
>> 
>> 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.
>
> I'm fine with this, perhaps immediately after 2.17.0 comes out?
> Provided that the regtests compile, I have no trouble switching to
> it for 2.17.1 regardless of what that might do to user scores
> (since nobody should be using 2.17.1).
>
> Note that GUB will need to be updated to compile guile V2, and
> also that if that update is done poorly then GUB would lose the
> ability to compile 2.16.x.  IIRC that happened with the 2.12
> branch, or at least the compile needed some manual hacks in order
> to complete the build.

The problem I am seeing here is a scheduling problem.  We have two
pent-up changes.  One is changing from Guilev1 to Guilev2.  The intended
user-visible change is no change at all except for performance.

Another is incorporating the new skyline code.  The intended
user-visible change is lots of change.  The skyline code is also likely
to cause significant performance impact that will want ironing out.

It seems to make comparatively little sense to do this ironing out based
on the Guilev1 architecture: while any reduction in computation
complexity will remain valid, the constant factors at very least will
all be quite different.

On the other hand, the skyline "patch" is quite large by now.  Rebasing
it on a Guilev2 architecture will only be feasible if we try keeping it
as similar as possible.  Which would favor a "minimally invasive"
Guilev2 migration, one that does not in its first iteration require
reorganizing the source code into independently compilable Scheme source
modules: that would be attempted only after the skyline code has been
successfully merged.

Tricky.

-- 
David Kastrup