Re: %module-public-interface

[Ian Hulin <ian@hulin.org.uk>]

On 02/04/10 10:37, Ludovic � wrote:
> Hi Ian,
>
> Ian Hulin<ian@hulin.org.uk>  writes:
>
>    
>> On 30/03/10 22:52, Ludovic � wrote:
>>      
>    
>>> Andy Wingo<wingo@pobox.com>   writes:
>>>
>>>        
>>>> On Tue 30 Mar 2010 22:56, ludo@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 (graham@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 (pnorks@gmail.com).

Cheers,

Ian