lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"
Date: Sun, 08 Mar 2020 15:04:17 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]