(For especial attention of Graham, Bug Squad, David, Bertrand and
\markup rewrite hackers)
Hi all,
I've been hacking away in the Guile V2 migration cave working on
Tracker 1686. This is to provide LilyPond with the ability to produce
compiled Scheme files which we can load and use and eventually
make-install into a known area as part of installing the binary kit.
This is so we can avoid using Guile V2 auto-compile which is fine and
dandy in its way but is a complete black box and one for which there
is no control over where the compiled go or what they are called.
Obviously useless in a project like LilyPond where you need to know
what the files are called and where they are so you can move them
during installation to where you need them to be.
During the course of hacking on my Guile V2 laptop system the
following "collateral damage" issues have cropped up in order to allow
Lily on a Guile V2 system to get through phase one of initialization
(that's the bit where we run up lily.scm from the image and load all
the other scm/*.scm files to build the (lily) guile module. The base
change for 1686 would require changes to lily/main.cc and
scm/lily.scm, but in order for these to fly I need to do the following:
o Move the safe-objects guile data definition and define-safe-public
macro into a new (scm safe-utility-defs) module
- add (use-modules (scm safe-utility-defs)) to lily.scm
- add (use-modules (scm safe-utility-defs)) to other scm/*.scm
files using the define-safe-public macro.
o Move all the markup macros and markup definition procedures to a new
(scm markup-facility-defs) module (this is the artist formerly known
markup-macros.scm and the remaining code in markup.scm)
- add (use-modules (scm markup-facility-defs)) to all the scheme
files that use the define-markup-command,
(especially define-markup-commands.scm).
- reorder declarations in define-markup-commands.scm so they don't
forward-reference commands not yet declared (#line is the real
killer, as it is implicitly used in the
compile-markup-expression and compile-all-markup-expressions
procedures).
- change the validation for lookup-markup-command-aux to look
explicitly in the (lily) module for markup commands already
defined rather than in the current module as the Guile
compile-file changes (current-module) to an anonymous module and
this breaks our code. (Yes, I know it's a Guile bug but life is
too short not to work around it while I beat up the Guile
developers and convince them it really is a problem).
OK, here's the question, what's better for our
development/bug-tracking/project management process - add a new
tracker for each of the two modules and mark them as blocking 1686, or
put up patch-sets for each of these as part of Issue 1686, and then
when they've been reviewed, counted down and pushed, put up the final
changes to lily.scm and main.cc, and when this one is reviewed,
counted down and pushed, then we can verify the issue.
By the way, the criteria for verifying all of these patches is that
they do no harm when running the LilyPond regression tests using Guile
1.8.
Cheers,
Ian Hulin
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
