Am Sonntag, den 08.03.2020, 16:28 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > [email protected] > > writes: > > > Am Sonntag, den 08.03.2020, 15:04 +0100 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > [email protected] > > > > > > > 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
