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:28 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > writes:
> 
> > Am Sonntag, den 08.03.2020, 15:04 +0100 schrieb David Kastrup:
> > > Jonas Hahnfeld <
> > > address@hidden
> > > 
> > > > writes:
> > > > How about the attached change? This attempts to locate the .pc file
> > > > next to guile-config and tries to be very transparent about this. If it
> > > > finds a directory, it restricts pkg-config to look only there. This
> > > > should work with non-default installations of Guile, at least it works
> > > > for a test setup on my machine.
> > > 
> > > Ok, I am obviously missing something important here.  You go to a lot of
> > > pain to use pkgconfig when someone specifies guile-config.
> > 
> > Right, I should have done a better job explaining the rationale
> > here. I agree that just setting GUILE_CFLAGS and GUILE_LIBS based on
> > guile- config will likely work, for now.
> > 
> > However as Werner described yesterday, we might want to modularize our
> > aclocal.m4. As part of that, we'll likely end up using the official
> > guile.m4 which relies on pkg-config.
> 
> Correct me if I am wrong, but the "official" *.m4 files basically
> implement tests.  The framework calling and interpreting those tests is
> basically in configure.in and quite up to us.
> 
> In addition, any non-standard tests could be done locally by us,
> probably mostly relying on the standard tests but augmenting them.

That's exactly what I want to avoid: IMHO it's a maintenance nightmare
to "augment" standard checks. Either they work as they do for everybody
else or we are doing something wrong.

> 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.

Jonas

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