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: David Kastrup
Subject: Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"
Date: Sun, 08 Mar 2020 12:34:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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.

>> This would concern things like running Patchy, and also things like
>> checking out pretests of stable releases for system packages.  If the
>> spec files of the stable release fails mysteriously, most users will
>> give up.
>
> With the patch it doesn't fail "mysteriously" - there's a clear error
> saying what the tester is supposed to do. And from my understanding
> "unstable" releases really means that.

Prereleases aren't as unstable.

>> I cannot believe the resistance against creating a few dozen lines
>> for making the life for users and testers of LilyPond easier and
>> insisting on a configuration that will fail for everything except a
>> single painstakingly "correct" use that is not documented.
>
> As I wrote yesterday, the whole thing wasn't documented before.

That's not something to be proud of.  It means that things tended to
work by heresay and recipes passed around that took some pain to figure
out.  It's not a state to aim for.

> I politely ask to take a step back and try to understand the point of
> view shared by Werner, Han-Wen and me.

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.

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.

-- 
David Kastrup



reply via email to

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