Re: guile-2.0 and debian

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2016-11-23 9:34 GMT+01:00 David Kastrup <address@hidden>:
>> Antonio Ospite <address@hidden> writes:
>>
>>> On Wed, 23 Nov 2016 00:25:03 +0100
>>> Thomas Morley <address@hidden> wrote:
>>>
>>> [...]
>>>> Hi Antonio,
>>>>
>>>> I figured to do a regtest-comparison between builds with guile 1.8.8
>>>> and guile 2.0.13:
>>>>
>>>> For that I had to get back guile 1.8.8 and did a build from current master,
>>>> then I did 'make test-baseline'.
>>>> Then I copied the entire folder 'lilypond-git/build/input' elsewhere.
>>>>
>>>> As second step I got guile 2.0.13 back
>>>> (Which is pretty tedious, because it's not in the distro, even not for
>>>> Ubuntu 16.10, if I'm not mistaken.)
>>
>> Isn't 2.0.12 sufficient?
>
> I _think_ 2.10.12 would be sufficient.
> But I read this correctly:
> https://launchpad.net/ubuntu/+source/guile-2.0
> then there's no guile 2.10.12 in Ubuntu and 2.0.11 does _not_ work.

Ok.

> Which leads me to the question, how we should proceed, if we really
> manage to get 2.0.12/13 working sufficiently?
>
> I imagine a plethora of users not having 2.0.12 and no reasonable
> chance for average users to get it.

We'll want to keep compilable with Guile 1.8 for now.  When configure
finds Guile less than 2.0.12, it will bomb out.

Our Gub packages compile with their own version of libguile (correct?)
so they should not be affected.  If configure bombs out for not-current
versions of Guile 2.0 for distributors, they will likely update Guile.

I don't think we currently have a sane strategy for Guile's *.go
compilations of LilyPond yet: I think they should come precompiled and
preinstalled.  Before that is the case, I don't think it makes sense to
_not_ mark Guile 2 support as experimental, including requiring the
--enable-guile2 option (or what it was called).

Of course, who does the work gets to call the tune.

-- 
David Kastrup