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

[Jonas Hahnfeld]

Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > writes:
> 
> > Am Samstag, den 07.03.2020, 10:37 +0100 schrieb Werner LEMBERG:
> > > > > > Is there anybody who recently built with a non-system version of
> > > > > > Guile-1.8 intentionally?
> > > > > I do this all the time.
> > > > So how did you do it last week?
> > > 
> > > 
> > > I updated my build script, see below.  Note that I install texi2html
> > > 1.82 and guile 1.8.8 in `/uar/local/opt`.
> > > 
> > > > > Usually, I try to insist on good documentation if people implement
> > > > > stuff differently.  This time it slipped my attention that
> > > > > Han-Wen's changes w.r.t. pkg-config are not properly described.
> > > > In this case, I don't think it is sufficient to add documentation
> > > > somewhere (though necessary).  People also need to get guided there
> > > > instead of stealthily making previously working options do nothing.
> > > 
> > > 
> > > As I said: I believe the proper action is to make LilyPond's
> > > `configure` script emit a warning if it finds GUILE_CONFIG set.
> > 
> > I disagree: Why do we have to keep everything compatible for a new
> > *major* release like it used to be in the past? That's very prohibitive
> > of any substantial change.
> 
> We are not talking about "keep everything compatible".  We are talking
> about making changes in a manner where they don't trip people up.  They
> way to deprecate a way of doing things is not to _start_ by pretending
> it never existed and silently ignore attempts to use it.  At the same
> time, by the way, not adapting any bit of documentation.

Acknowledged.

> For better or worse, deprecation takes work.  That's why we have, for
> example, convert-ly.  That's a user-level feature, but basically
> asserting that people able to compile LilyPond have to be able to deal
> with anything we throw at them without comment is not going to go down
> well with regard of keeping LilyPond supported by, say, major GNU/Linux
> distributions.

Do expect "major GNU/Linux distributions" to package unstable
releases? I hope we don't force them by taking another 6 years for 2.22

In the long run I'd expect "major GNU/Linux distributions" to ditch
Guile 1.8, and I hope we can do the same in LilyPond not so far in the
future. That will be so fundamentally different that not being able to
use the GUILE_CONFIG environment variable is the least of your changes
you have to make for your build configuration. Btw upstream deprecated
guile-config, so pkg-config is really the way to go.

Jonas

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