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

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

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 .

> Now we can of course try to re- implement all functionality from there
> using guile-config. But that's a major distraction and exactly what
> I'm fearing contributors working on the build system will have to do.

I can assure you of two things:
a) I would not consider that a reasonable thing to do.
b) I don't call the shots.
We still work on a base of loose consensus here.  I may seem to carry a
lot of weight, but that's mainly because I am thick-headed and
persistent, and because I tend to make sense.

And while I am thick-headed, I am not an idiot (I realise that a lot of
people will disagree with that assessment, but it's probably easier to
humour me on that one).  So if you base your decision-making now on the
persuasion that I will not try adapting the kind of decisions and
opinions formed now to future situations, I think you are making life
harder for everyone involved than strictly called for.

> Again, sorry for not spelling out all this from the very beginning; I
> just don't have a clear understanding yet how these things will work
> out at the end. What I want to avoid, and that's why I have been (and
> still am) imposed to this type of compatibility, is that legacy things
> get into our (my) way of modernizing the build system.

That's a good reason for keeping things modular, and for rethinking
decisions when circumstances change.  Which also is aided by keeping
things modular, namely making sure that the consequences of isolated
strategic decisions are not littered all over the place but kept in
identifiable stretches of code.

> It already is a mess (speak up if you disagree

It's almost insulting to even contemplate my disagreement.  There is
comparatively little in my work on LilyPond that doesn't fit the
characterisation of making things less messy in programming, solving
problems, using and working with LilyPond.  And I have had very little
contact to LilyPond's build system.  One reason I am completely out of
my depth when trying to tackle something like
<https://sourceforge.net/p/testlilyissues/issues/5822/> where I loosely
bolt on stuff on existing procedures and (mostly futilely) beg people to
check that some of my bolts are somewhat in the right place.  And ask
them to tell me where else they should get fitted.

> and I'll happily point you to places that I already cleaned up or that
> still need IMO). Working on it is complicated enough, even without
> having to do archaeological research on what used to work in the past
> and how to make new things work in old environments.
>
> That said, I also want 2.21.0 to happen soon - I was hoping we could do
> it this weekend. Now we have a blocker, introduced by a change more
> than a week ago. And it's in the build system, something that I
> absolutely wanted to avoid this last week for non-trivial cleanups as
> to not break GUB again.
> Do you understand the dilemma I'm facing?

Sure.  I was not in the position where I could have told people
authoritively (and "authoritively" I never am) to stop doing major work
on master.  And I would want to avoid the situation where we have to
release unstable releases (even something like 2.21.0) from a curated
branch rather than master.  The time plan of 2.20 and 2.21 was
reasonably clear (even if somewhat optimistic) after Salzburg, so I
relied on a mixture of luck and appeal to responsibility and insight for
making stuff work out.  It would have been nice to either not have to
deal with large changes of build infrastructure, or to be progressed
enough with it that one could confidently cater for special cases.

That's not in every respect how things turned out, and I would not want
to have it otherwise, either: I am glad we made the progress we did.

Nevertheless, we want to find a minimally invasive solution that will
tend to "just work" without major modification for people without having
to change in the user/compiler related respects a whole lot in short
course.

I think a safe step right now is for Werner to update the upstream
pkgconfig autoconf support.  Whatever we end up with, there is no point
in designing a solution that does not involve that as a component.  I
wanted to suggest him fast-tracking that change separately because of
that.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".