Re: Autocompilation/LilyPond

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>>> In the long run, I think this is probably your best way forward, but
>>> admittedly it would require more work to make this transition.
>>
>> The main problem is that it requires such a large reorganisation of the
>> LilyPond sources that the attempts to do it in that manner tended to
>> consist of outdated nontrivially rearranged parts before getting through
>> peer review successfully.  LilyPond is quite a moving target.
>>
>> Ian Hulin has mostly worked on Guilev2 migration in that manner, and it
>> has caused him to do lots of futile work, a major cause of frustration
>> for him and of worry for others because the large reorganisations made
>> the work hard to verify.
>>
>> So while this might be the "if everything was written from scratch, it
>> would make most sense to do it this way" approach, it has proven less
>> than fabulous as a migration strategy [...]
>
> Okay, understood.  The other alternatives are workable, with the build
> script written in Scheme probably being the most future-proof of the
> remaining options.

Sounds somewhat like it.

> It occurs to me that if the "lilypond module" has not already been set
> up,

I think it will be.

> then it will be completely empty and not suitable for compiling
> anything, so in that case you'll want to do something closer to this:
>
>   (define lilypond-module (make-fresh-user-module))
>   (module-use! lilypond-module (resolve-interface '(guile)))
>   (set-module-name! lilypond-module '(LILYPOND MODULE NAME))
>   (set-current-module lilypond-module)
>   (for-each (lambda (base-name)
>               (let ((scm-file-name (string-append base-name ".scm"))
>                     (go-file-name  (string-append base-name ".go")))
>                 (compile-file scm-file-name
>                               #:output-file go-file-name
>                               #:env (current-module)
>                               #:opts %auto-compilation-options)
>                 (load scm-file-name)))
>             <LIST-OF-BASE-NAMES>)
>
> BTW, if I wanted to take a look to try to get it working myself, what
> branch of the lilypond git repo should I look at?

Believe it or not, master.  There is nothing in the public repository
that would have more progress regarding Guilev2 migration (it might make
sense to ask Ian whether you can pull something from him).  master is
always kept in a state where it compiles, passes regtests, and builds
the documentation, and should not trail the "staging" branch (where new
changes get pushed) for more than a day.  Unless "staging" does not pass
the tests, in which case the automated push does not proceed.

You can look for open issues regarding Guilev2 migration in
<URL:http://code.google.com/p/lilypond/issues/list?can=2&q=guile>

Various issue carry patches.  I think the one where Ian ran out of steam
on last had been
<URL:http://code.google.com/p/lilypond/issues/detail?id=2026>

Note that the problems occuring here are not all particularly related to
Guilev2 or its directory layout.  But whenever there was non-trivial
delay, Ian had to start reorganizing the source tree from scratch or try
tracking recent changes back into his version.  So each of the
comparatively small problems in migrating meant that he had to start
over.  And it meant that it was very hard to verify his work since there
was a large reorganisation each time.

So while it may all seem like a huge bunch of unnecessary stupidity, the
"proper" way to do this has, in practice, shown itself to result in
motivationally devastating effects.  We need a migration strategy with
more incremental psychological rewards and less fear (namely, something
that is better verifiable than a large reorganisation of the source).

We mostly have to rely on working with humans.

-- 
David Kastrup