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

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Samstag, den 14.03.2020, 11:36 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> address@hidden
>> > writes:
>> 
>> > Am Samstag, den 14.03.2020, 11:17 +0100 schrieb David Kastrup:
>> > > Jonas Hahnfeld <
>> > > address@hidden
>> > > 
>> > > > writes:
>> > > > Am Samstag, den 14.03.2020, 10:50 +0100 schrieb David Kastrup:
>> > > > > Jonas Hahnfeld <
>> > > > > address@hidden
>> > > > > 
>> > > > > 
>> > > > > > writes:
>> > > > > > Am Freitag, den 13.03.2020, 23:09 -0600 schrieb Anthony Fok:
>> > > > > > > On Fri, Mar 13, 2020 at 2:02 AM Jonas Hahnfeld <
>> > > > > > > address@hidden
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > > wrote:
>> > > > > > > > I'm still not convinced that we need compatibility code, but 
>> > > > > > > > I'm happy
>> > > > > > > > with anything that gets us to a release and is not technically 
>> > > > > > > > wrong.
>> > > > > > > 
>> > > > > > > By the way, from a Debian package maintainer point of view, 
>> > > > > > > breaking
>> > > > > > > backward compatibility is OK as long as it is documented, so if
>> > > > > > > breaking backward compatibility makes the code cleaner, more 
>> > > > > > > correct,
>> > > > > > > and/or easier to maintain for the future, I'd say "please break
>> > > > > > > compatibility"!
>> > > > > > 
>> > > > > > I definitely think that's the case here.
>> > > > > 
>> > > > > Backward compatibility will always get retired eventually.  For the
>> > > > > current decision the main target is not really distributions since 
>> > > > > those
>> > > > > tend not to package unstable versions anyway.
>> > > > 
>> > > > Exactly my argument in the past. So who is the "main target" in your
>> > > > opinion? I mostly remember the term "system integrators".
>> > > 
>> > > Is there a reason we should not be catering well to either?
>> > 
>> > I still don't understand who your "main target" is. Wrt "system
>> > integrators" Anthony wrote that breaking compatibility is fine (for
>> > major versions) as long as there is documentation.
>> 
>> Our current state is breaking things silently and without documentation
>> that were required to get things working before.
>> 
>> The consequences are different for different people, depending on their
>> contact with LilyPond and their skill sets in dealing with such
>> problems.  This is a problem with keeping our current processes
>> depending on volunteers operating as expected.  That also maps to people
>> expected to compile their own versions.  Distributions like those for
>> Debian, FreeBSD and more recently also MacOSX work independently from
>> our core developer team and should be able to get results they expect.
>> 
>> What is the problem you are trying to address with your "main target"
>> question?
>
> I'm trying to find a way forward so we can get 2.21.0 released.

It's not stuck on the discussion, sorry if you got that impression.
I'll try doing the respective minimal changes I think necessary today.
I've been procrastinating on those, partly because of tooth problems,
probably due to a cracked tooth that got patched up with a filling (I
don't have the means for more thorough work) the day before yesterday
and hopefully will stop making problems for a while now that it's
somewhat less likely to admit bacteria into its innards.

> I've thrown out a few ideas which you've all said we should not do. So
> what do you want?! This discussion is dead without knowing that.
>
> Let me rephrase what I think we should do:
> 1) Keep using pkg-config to find Guile.
> 2) Add an error if we detect that a configuration uses the old
> GUILE_CONFIG.
> 3) Add documentation about how to make pkg-config find the right
> version of Guile, saying that 1.8 is still the one you should target
> for now.

As I said, at the current point of time a warning is heeded at most when
GUILE_CONFIG is being used, and overriding the Guile compilation and
linking flags is already documented by Werner's patch, so not allowing
that in principle makes no sense.

Settings and environment variables that are heeded need to get saved
from one invocation to the next: I still have to check whether this will
also be the case when we set the variables for compiling/linking via
checking and detecting GUILE_CONFIG.

I need to get this done and verified.  That does not really depend on
discussions, more on that I get my lazy ass to move.

-- 
David Kastrup