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

[Jonas Hahnfeld]

Am Sonntag, den 08.03.2020, 15:04 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > writes:
> 
> > Am Sonntag, den 08.03.2020, 13:37 +0100 schrieb David Kastrup:
> > > At any rate, can we focus on the issue at hand rather than building our
> > > strawmen from straw of future harvests?  We have a current issue that
> > > has already bitten several not-completely-stupid developers (even if you
> > > disagree with that characterisation, we just cannot afford further
> > > restricting the qualifications for being allowed to work with LilyPond),
> > > so it is reasonable to assume that it will affect also people outside of
> > > the core team.
> > > 
> > > This issue is a lot less likely with things other than libguile.
> > 
> > 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.  Now let's
> just assume that someone uses guile-config because they either don't
> know better or it's the easiest way to muddle through (which makes being
> transparent about what happens a very good idea either way): is there a
> fundamental drawback in just using guile-config then?
> 
> Now make no mistake: most of the work invested into using pkgconfig in
> this patch actually _is_ beneficial (even should we decide to use
> guile-config in the end) in that it leads to being able to make a very
> pinpointed (and even tested as workable) suggestion to the user what to
> do in future.
> 
> So I am definitely grateful for the work you put in here, and whatever
> we decide, the bulk of it will be put to good use.  But apparently there
> is a good reason for you not wanting to see guile-config used even if
> specified (which technically means that the user can only blame
> themselves if something goes wrong), and that reason likely revolves
> around a technical consideration or necessity, one that likely should
> also apply to whoever feels using GUILE_CONFIG is a good idea.
> 
> Is there any more to it other than "it has been deprecated"?  I feel
> like I am missing some aspect of what is involved here.

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. 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.
This may sound abstract at first, but just think of compiling the
Scheme code into .go files. As far as I understand, this requires the
guild program - which we can easily get from GUILE_PROGS, called in a
single line.

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. It already is a
mess (speak up if you disagree 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?

Jonas

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