lilypond-devel
[Top][All Lists]
Advanced

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

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without


From: Jonas Hahnfeld
Subject: Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"
Date: Sat, 07 Mar 2020 12:38:11 +0100
User-agent: Evolution 3.34.4

Am Samstag, den 07.03.2020, 11:34 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > writes:
> 
> > Am Samstag, den 07.03.2020, 08:54 +0100 schrieb David Kastrup:
> > > David Kastrup <
> > > address@hidden
> > > 
> > > > writes:
> > > > If I previously did
> > > > 
> > > > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config ./configure
> > > > ./config.status --recheck
> > > > 
> > > > then the Guile configuration was reused.  If I now do
> > > > 
> > > > PKG_CONFIG_PATH=/usr/local/tmp/guile-1.8/lib/pkgconfig ./configure
> > > > ./config.status --recheck
> > > > 
> > > > the configuration information is lost and configure reverts to the
> > > > system configuration.
> > > > 
> > > > In addition, PKG_CONFIG_PATH is not documented in our configuration or
> > > > with ./configure --help.
> > > > 
> > > > How to fix?
> > > > 
> > > > A documented option --with-guile-prefix or --with-libguile-prefix that
> > > > puts up a working configuration might be a reasonably transparent and
> > > > future-safe option.
> > > > 
> > > > Also now I don't think it made sense to _remove_ the GUILE_CONFIG
> > > > variable: if it's set, it seems worth heeding.  If it's unset, going via
> > > > pkgconfig may be the right way.  --with-libguile-prefix could pick the
> > > > right option underneath, checking that it is viable, and prefer using
> > > > PKG_CONFIG_PATH .
> > > 
> > > To put this into perspective: this definitely is a showstopper for
> > > 2.21.0.  A quick fix would be reverting the whole patch for issue 5780
> > > in order to get back to a compatible state to what we had previously.  A
> > > minimum fix would be recovering use of GUILE_CONFIG (when it is being
> > > specified) in order to get back to the previous state of usability.
> > > Given that I had several segfaults with GUILE-2.2 in recent days, I also
> > > strongly lean towards continuing to require --enable-guile2 for getting
> > > Guile2+.  We can reword the "highly experimental" bit.
> > > 
> > > At any rate, INSTALL.txt does not reflect _any_ of these changes.  It
> > > states
> > > 
> > >    • Guile (
> > > http://www.gnu.org/software/guile/guile.html
> > > 
> > > ) Use version
> > >      1.8.8.  Version 2.x of Guile is not currently supported.
> > 
> > I disagree that it's a showstopper for 2.21.0: It's different than
> > before, true, but it works (if you know how to do it).
> 
> "It works if you know how to do it" is elitist talk.  It's not
> release-ready when there is no documented way of doing it.

 $ git grep GUILE_CONFIG origin/stable/2.20
shows matches in Documentation/misc/ChangeLog-2.1 (no typo, really that
old), aclocal.m4 and config.make. So already using GUILE_CONFIG before
has been guessing our build system without documentation.

Nevertheless please let me know where you want the documentation to go
and I volunteer to copy Werner's text there. I don't want the release
to blocked on something like this.

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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