On 16/12/11 17:51, David Kastrup wrote: > Ian Hulin <i...@hulin.org.uk> writes: > >> Guile V2 insists on some thing, particularly macros being >> defined before they are used. > > That's not unreasonable. > >> When Patrick M. first tried out using Lily with Guile 2, the only >> way we could use it was by relying on the equivalent of the >> Guile --auto-compile option. > > What do you mean with "equivalent"? In Guilev1, it is not even > defined. > Ah, you mistook my meaning. What I meant was there is a new --auto-compile CLI option in Guile 2 which is automatically switched on in the API. It was intended as a help by the Guile developers for migration, but there were some unfriendly feature from our point of view introduced at the last minute in the vanilla Guile API.
This meant that we had to roll our own code to produce or byte-compiled files to ensure a) we knew exactly where they ended up and b) we had some control over what they were called. Hence our tracker Issue 1686. In order to roll our own compilation code one of the changes in main.cc will be to turn the Guile 2 --auto-compile option off. However modularising the markup code buys us two things, one we have a back-stop in case we have to fall back to relying on Guile V2 auto-compile for the migration, two all of this unloved home-brew interpreting code is partitioned off from the rest of the LilyPond Scheme code. I'll have a think about your other comments and answer them in is separate post. Cheers, Ian _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel