On 02/04/10 10:37, Ludovic � wrote:
Hi Ian,
Ian Hulin<i...@hulin.org.uk> writes:
On 30/03/10 22:52, Ludovic � wrote:
Andy Wingo<wi...@pobox.com> writes:
On Tue 30 Mar 2010 22:56, l...@gnu.org (Ludovic Courtès) writes:
I'm pretty sure that the submodule thing can be changed without any
problem. But it seems that the %module-public-interface is used
explicitly, at least by texmacs and lilypond.
How do they use it?
Linking to the evil empire:
http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search
http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface+lang%3Ac%2B%2B&sbtn=Search
Lilypond does:
--8<---------------cut here---------------start------------->8---
mod = scm_call_0 (maker);
scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
mod);
--8<---------------cut here---------------end--------------->8---
Solution: do something like:
--8<---------------cut here---------------start------------->8---
#ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
scm_set_module_public_interface_x (mod, mod);
#else
scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
mod);
#endif
--8<---------------cut here---------------end--------------->8---
(We just need to add that function.)
TeXmacs does:
<snip>
And we could add a ‘public-interface’ slot to ‘module-type’ and have
‘module-public-interface’ and ‘set-module-public-interface!’ refer to
it; for backward compatibility we’d also initialize the
‘%module-public-interface’ binding. How does it sound?
Actually the trick wouldn’t work in cases where the
‘%module-public-interface’ binding is mutated, as with Lilypond.
Given this and the above examples, I’d suggest dropping that binding
completely and sending patches to the Lilypond/TeXmacs people.
What do you think?
If you do add scm_set_module_public_interface_x, could you back-port
it to Guile V1.8.6 and V1.8.7?
We could back-port it to the 1.8 series, but not to the already-released
1.8.7 and 1.8.6. We’d have to make a 1.8.8 release, but I’m not sure
that would really help anyway since that would force Lilypond users to
switch to that version.
Those are the lowest versions of Guile the upcoming stable release of
Lilypond will support.
How about doing #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X in your
code?
We still have to agree on the change and actually implement it, the
latter being easy. ;-)
I'm sure that would be easy enough, if guile provided
HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X in the V2.0
guile-config (or the pkg-config guile-2.0 data which I believe is
replacing it), that looks like it would be the most painless route for
both projects.
When is the new Lilypond release due?
I'm not the ReleaseMeister for Lilypond; you'll get a better picture by
talking to Graham Percival (gra...@percival-music.ca).
But FWIW it looks like we're on our few last development releases before
the stable V2.14 comes out. It's near enough for a spoof release
announcement to have gone out on the mailing list on April 1st which
suckered me!
I reckon plans are for Lilypond to stick with Guile V1.8.7 at least
until the next Lilypond stable version after V2.14, but again, mileage
may vary if you talk to more experienced Lilypond people.
Currently there are only a couple of people in the Pond looking at
Lilypond/Guile V2.0 transition, and there are a few compatibiilty
breakages we've identified.
1. Lilypond configure looks at guile-config --version to get the guile
version - the guile V2.0 guile-config says it's being deprecated in
favour of pkg-config --atleast-version/--exact-version/--max-version.
2. Lilypond has *lots* of guile code which it needs to build the project.
3. There's a restriction introduced in Guile V2.0 whereby dynamic use
of define, define-public and variants will cause the guile compilation
to fail with diagnostics. We have these in our basic Scheme files
(lily.scm and lily-library.scm). These compilation failures currently
stop Lilypond building altogether.
4. We've already seen the %module-public-interface thing in the Lily
C++. There's probably more smelly stuff lurking in the C++ interface,
which won't surface until we start trying to use Guile 2.0 more.
Graham, Vincent, is it worth opening a tracker to capture
forward-compatibility issues with Guile?
Thanks for your feedback so far, Ludo. The other Lily developer who has
done anything with Guile 1.9/V2.0 is Patrick McCarty (pno...@gmail.com).
Cheers,
Ian
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
