Re: Autocompilation/LilyPond

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> How is this supposed to work for compiling and installing a package?
>> Basically,
>>
>> make all
>> sudo make install
>>
>> The usual case will be that the user calling lilypond will not have
>> write permission in the installed directories (and even if he did, like
>> when calling lilypond as root, lilypond should not stomp over the
>> installed files).
>>
>> So what would make all do to generate one or more .go files?
>
> I'm not very familiar with the build system, so it would be great if
> Ludovic or Andy could chime in here, but as I understand it, the way
> it's meant to work is as follows:
>
> Ideally, each file contains a single module, whose name matches its own
> pathname relative to an element of the GUILE_LOAD_PATH, with a
> (define-module ...) header at the top declaring its dependencies on
> other modules (using #:use-module) and its exports (using #:export and
> #:export-syntax).  See guile-2.0.5/modules/* for many examples, and
> section 6.19.3 (Creating Guile Modules) for reference.

That's not really all that feasible: many of the dependencies are
implied in the load order, and it would be rather awkward to put an
explicit #:use-module for every part previous in the order.

> If you do this, then you don't have to worry about what order you use
> to compile or load things, and you can use the 'guild compile' command
> to compile each file to a .go file.  See section 6.17.5 (Compiling
> Scheme Code) in the manual for more details.  For example:
>
>   $ guild compile -o foo.go foo.scm
>   wrote `foo.go'
>
> 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 and is probably the major cause
that Ian and myself probably don't have the most happy thoughts when
thinking about each other.

So an approach that does not require manual declaration of dependencies
would certainly help.

> So now I will outline a couple of other options that require much less
> work.

I'll have to look at them.

-- 
David Kastrup