Re: Autocompilation/LilyPond

[Mark H Weaver]

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.

Then, when you boot Lilypond, instead of using 'load' to load these
files, you'd instead use 'use-modules', which would both load the .go
files and import all of their exported definitions into the main
Lilypond module.

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.  So now I
will outline a couple of other options that require much less work.

You could write a little Scheme script that gets run by the Lilypond
build system to create the .go files.  This script would first set the
current module to whatever it will be when the Lilypond scheme files are
loaded at runtime, and then compile and load the .scm files in the
appropriate order, using something like this (untested) code:

  (set-current-module (resolve-module '(LILYPOND MODULE NAME)))
  (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>)

By compiling and loading each file in sequence, the macro definitions of
the earlier files will be available to the later files.

Alternatively, you could simply run Lilypond itself during the build
process, with the XDG_CACHE_HOME environment set to something in the
build directory so that the auto-compiled .go files will end up there.
However, this solution seems a bit less robust to me, as I could imagine
some day changing our policy of where the auto-compiled files are
placed.

Again, this is not my area of expertise, so hopefully Ludovic or Andy
could take a look at what I've written here and let us know if I made
any mistakes.

     Best,
      Mark