[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Autocompilation/LilyPond
From: |
David Kastrup |
Subject: |
Re: Autocompilation/LilyPond |
Date: |
Tue, 06 Mar 2012 02:03:57 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Mark H Weaver <address@hidden> writes:
> David Kastrup <address@hidden> writes:
>
>> Mark H Weaver <address@hidden> writes:
>>
>>> David Kastrup <address@hidden> writes:
>>>
>>>> with the stable release 2.16 of LilyPond looming around the corner, it
>>>> will become imminent soon to think about supporting Guile 2.0.
>>>>
>>>> Previous attempts have mostly exploded around the problem that we have
>>>> something like
>>>>
>>>> (for-each ly:load init-scheme-files)
>>>>
>>>> in our lily.scm file, and the auto-compiler attempts to compile all
>>>> of those files independently as far as I understand. Unfortunately,
>>>> some of them contain macro definitions that other files rely on.
>>>>
>>>> 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.
>>>
>>> I'm not sure that would help much. There's a deeper problem that you
>>> should be aware of. In Guile 1.x, macro uses within procedures are
>>> not expanded until the procedure is evaluated. In Guile 2, macros are
>>> expanded as soon as the procedure is defined, even if compilation is
>>> turned off. This means that functions can only use macros that were
>>> previously defined.
>>
>> I don't think that making this condition hold would be really hard.
>> LilyPond has a rather carefully selected load order in several stages,
>> so use-before-definition, whether in the context of macros or not,
>> should be more the exception than the rule, and only require smaller
>> rearrangements.
>
> 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.
--
David Kastrup
- Autocompilation/LilyPond, David Kastrup, 2012/03/05
- Re: Autocompilation/LilyPond, Mark H Weaver, 2012/03/05
- Re: Autocompilation/LilyPond, David Kastrup, 2012/03/05
- Re: Autocompilation/LilyPond, Mark H Weaver, 2012/03/05
- Re: Autocompilation/LilyPond,
David Kastrup <=
- Re: Autocompilation/LilyPond, Mark H Weaver, 2012/03/05
- Re: Autocompilation/LilyPond, David Kastrup, 2012/03/07
- Re: Autocompilation/LilyPond, Mark H Weaver, 2012/03/09
- Re: Autocompilation/LilyPond, David Kastrup, 2012/03/09
- Re: Autocompilation/LilyPond, Mark H Weaver, 2012/03/09
- Re: Autocompilation/LilyPond, David Kastrup, 2012/03/09
- Re: Autocompilation/LilyPond, Ian Hulin, 2012/03/10
- Re: Autocompilation/LilyPond, David Kastrup, 2012/03/10
Re: Autocompilation/LilyPond, Ludovic Courtès, 2012/03/10