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

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Sonntag, den 08.03.2020, 12:34 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> address@hidden
>> > writes:
>> 
>> > Am Sonntag, den 08.03.2020, 11:54 +0100 schrieb David Kastrup:
>> > > Han-Wen Nienhuys <
>> > > address@hidden
>> > > 
>> > > > writes:
>> > > > > What about "an error would be a nuisance when trying to have a common
>> > > > > configuration for both 2.20 and 2.21" was unclear?
>> > 
>> > There will never be a shared configuration for both 2.20 and 2.21:
>> > Current master requires Python 3 which 2.20 not even attempts to be
>> > compatible with.
>> 
>> Many systems install both Python2 and Python3 and the respective
>> configure scripts are perfectly fine finding and using the required
>> version.  I wasn't trying to imply that we can share the _results_ of
>> running configure, but a common starting position, given the autoprobing
>> nature of autoconf, is a lot more realistic.
>
> My point is that setting the PYTHON variable is equally broken.

Can we argue actual problems rather than strawmen?  There has never been
a requirement to set the PYTHON variable for compiling LilyPond.

>> That basically amounts to "we can figure it out, so everybody else
>> should".  I don't doubt your competency, but it just isn't
>> representative for everyone wanting to use/compile/support LilyPond.
>
> No, it amounts to "it works the same as it does for other packages".

Other packages don't play the role Guile-1.8 does with LilyPond, for
better or worse.  That is the principal stumbling block for compiling
LilyPond on a current system.

>> It isn't, for example, representative for the people typically doing
>> git bisection in order to find out where something went wrong.  Hard
>> cutoff points in working configurations make something like bisection
>> a lot more painful.
>
> Not being able to change gradually makes development more painful.

You are not talking about gradual change.  You are talking about hard
change.  _I_ am talking about gradual change which you consider
unacceptable.

> There was discussion as to why there are so few developers - this will
> be my prime reason if I'm required to add compatibility for
> everything.  Yes, this includes things so fundamental as Guile.

Again, can we stop arguing strawmen?  I am talking about Guile (or more
exactly, libguile) while you continue to insist talking about
"everything".  Also as far as I can tell, you consider the current
situation without any documented way of getting a custom Guile-1.8
compilation to compile fine.  Because it is the same as getting some old
Freetype library to compile.

For LilyPond, those are not problems of equivalent prevalence.  I do not
want to imply that it is a good thing that we don't document how to
supplant _any_ system-provided library using pkg-config, but the
consequences for the project are quite worse in respect to libguile than
for libfreetype.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".