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

[Jonas Hahnfeld]

Am Sonntag, den 08.03.2020, 16:40 +0100 schrieb Jonas Hahnfeld:
> Am Sonntag, den 08.03.2020, 16:28 +0100 schrieb David Kastrup:
> > So I am reasonably confident that with some reasonably designed chunks
> > of code, we'd end up with comparatively small headaches in upkeep.  My
> > own gut feeling is that we'd not burn (or obstruct) any major bridges
> > supporting GUILE_CONFIG: if it is explicitly given, we don't really need
> > to check for versions or any other viability considerations: we can just
> > set the variables and be done.  That's small enough that I would not
> > have qualms putting it in configure.in .
> 
> If you're unhappy with the provided patch, I'd ask you to come up with
> something "reasonable" that you think is better.

Can we make progress on this issue and eventually start releasing 2.21?
Here's my take on why I think above approach doesn't work:
> Oh, turns out I need to strongly disagree with the last sentence: It's
> probably not of concern right now, but if we ever were to require Guile
> 2.x (I hope we're going to, and not only with 2.24) we should throw a
> hard error if a user presents us a guile-config from 1.8. Otherwise
> there will be linker errors, which are much harder to diagnose.

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.

Jonas

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