[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: %module-public-interface

From: Ian Hulin
Subject: Re: %module-public-interface
Date: Fri, 02 Apr 2010 12:58:47 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

On 02/04/10 10:37, Ludovic � wrote:
Hi Ian,

Ian Hulin<address@hidden>  writes:

On 30/03/10 22:52, Ludovic � wrote:
Andy Wingo<address@hidden>   writes:

On Tue 30 Mar 2010 22:56, address@hidden (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:
Lilypond does:

--8<---------------cut here---------------start------------->8---
        mod = scm_call_0 (maker);
        scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
--8<---------------cut here---------------end--------------->8---

Solution: do something like:

--8<---------------cut here---------------start------------->8---
    scm_set_module_public_interface_x (mod, mod);
    scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
--8<---------------cut here---------------end--------------->8---

(We just need to add that function.)

TeXmacs does:
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

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 (address@hidden).

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 (address@hidden).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]