lilypond-devel
[Top][All Lists]
Advanced

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

Re: Fedora 19 comes with guile 2.0.9 - cannot use 2.17.22


From: Ian Hulin
Subject: Re: Fedora 19 comes with guile 2.0.9 - cannot use 2.17.22
Date: Sat, 20 Jul 2013 22:00:50 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

On 13/07/13 20:51, Frédéric Bron wrote:
>> I don't think ./configure should do this automatically, but at
>> the very least, it should fail when it finds a guile version that
>> is incompatible with our source code. Can you please open an
>> issue for it\?
> 
> good point, I will do that. Frédéric
> 
Hi Frédéric,

Could you make the Guile-1 compatibility a separate issue from 3382,
which is about tex-info versions?

Here's a suggestion: add an --enable-guile-1-compatibilty option
defaulting to #t until the Guile 2 conversion cut-over.

If set to true this sets up the variables you mentioned to be exported
in make.

Once the Guile-2 conversion is complete, we reverse the default for
--enable-guile-1-compatibilty to #f.

aclocal.m4 is the bit which does the configure option parsing,

We'd need new internal variable guile_1_compatibility_b which then
controls declaring

    if test "$guile_1_compatibility_b" = yes; then
        AC_DEFINE(GUILE_1_COMPATIBILITY)
        DEFINES="$DEFINES -DGUILE_1_COMPATIBILITY"
        GUILE=" /usr/bin/guile1.8"
        GUILE_CONFIG=" /usr/bin/guile1.8-config"
        GUILE_TOOLS=" /usr/bin/guile1.8-tools"
    fi

This is untested but you get the idea.  Model the changes for
aclocal.m4 on the --enable-optimising/($)optimising_b sections.

I haven't looked at what would be needed in the makefiles but this
should give you or Julien a start.

WDYT?

Cheers,

Ian





reply via email to

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