Re: Autocompilation/LilyPond

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Mark H Weaver <address@hidden> writes:
>>
>>> Excellent!  As long as you load everything in the right order, such that
>>> macros are defined before they are used, I don't see why there should be
>>> any other problems related to macros and compilation.
>>
>> Because the individual files are not independent from one another?
>> That's why I wrote:
>>
>>     Personally, I think it would make sense if we could get the
>>     autocompiler to treat the whole blob of files as _one_ unit, and
>>     recompile the unit if it gets out of date.
>
> There's no problem with them being dependent on one another.  When you
> load a file, even with auto-compilation, the macro expander will make
> use of whatever macros are already bound in the current module.  The
> rest of the compiler sees only the output of the macro expander.
>
> Try the following experiment: put "(define-macro (bar x) `(quote ,x))"
> into "foo1.scm", and "(define (foo x) (bar x))" into "foo2.scm", and
> then within a REPL type: (load "foo1.scm") (load "foo2.scm") and observe
> that everything works as it should.
>
> If you really want everything to be compiled as one unit, you can use
> 'include' (which acts essentially the same as #include in C), though
> beware that Guile is not yet smart enough to auto-recompile when one of
> the included files gets updated.
>
> I don't see any compelling benefit to compiling everything as one unit,
> but do as you wish :)

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?

-- 
David Kastrup