David Kastrup <d...@gnu.org> 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