[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: |
Sat, 07 Mar 2020 09:12:53 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Werner LEMBERG <address@hidden> writes:
>> In addition, PKG_CONFIG_PATH is not documented in our configuration
>> or with ./configure --help.
>>
>> How to fix?
>
> I will take care of this. Reason is that in calls to `PKG_...`,
> `configure.ac` often uses the explicit argument `true`, which prevents
> the creation of default actions. For example, FreeType's
> `configure --help` output produces
>
> ...
> PKG_CONFIG path to pkg-config utility
> PKG_CONFIG_PATH
> directories to add to pkg-config's search path
> PKG_CONFIG_LIBDIR
> path overriding pkg-config's built-in search path
> LT_SYS_LIBRARY_PATH
> User-defined run-time library search path.
> ZLIB_CFLAGS C compiler flags for ZLIB, overriding pkg-config
> ZLIB_LIBS linker flags for ZLIB, overriding pkg-config
> BZIP2_CFLAGS
> C compiler flags for BZIP2, overriding pkg-config
> BZIP2_LIBS linker flags for BZIP2, overriding pkg-config
> LIBPNG_CFLAGS
> C compiler flags for LIBPNG, overriding pkg-config
> LIBPNG_LIBS linker flags for LIBPNG, overriding pkg-config
> HARFBUZZ_CFLAGS
> C compiler flags for HARFBUZZ, overriding pkg-config
> HARFBUZZ_LIBS
> linker flags for HARFBUZZ, overriding pkg-config
> BROTLI_CFLAGS
> C compiler flags for BROTLI, overriding pkg-config
> BROTLI_LIBS linker flags for BROTLI, overriding pkg-config
>
> and all of those messages are auto-generated.
So? This does not provide a documented way of getting Guile activated
at all unless you are a 14th level system building magician.
>> A documented option --with-guile-prefix or --with-libguile-prefix
>> that puts up a working configuration might be a reasonably
>> transparent and future-safe option.
>
> I think this is not really necessary; IMHO environment variables are
> good enough.
Not in the current state.
>> Also now I don't think it made sense to _remove_ the GUILE_CONFIG
>> variable: if it's set, it seems worth heeding. If it's unset, going
>> via pkgconfig may be the right way. --with-libguile-prefix could
>> pick the right option underneath, checking that it is viable, and
>> prefer using PKG_CONFIG_PATH .
>
> I disagree. In FreeType, I maintain having support for the old-style
> `xxx-config` scripts together with pkgconfig only for backwards
> compatibility reasons (since FreeType might be compiled on very old
> systems) – I don't do this for newer, optional libraries like
> 'brotli'. LilyPond isn't an important system library, so it's better
> to avoid this hassle given that environment variable support gets
> produced for free.
We aren't talking about LilyPond but about Guile. And we are talking
exactly about backward compatility reasons: not making configuration
options that previously worked fail. That makes LilyPond backwards
incompatible to system integrators.
And in this case, without a documented replacement. And not even
grepping will help with the "there is a way to get there, so we don't
need to implement or document anything" stance since there not even _is_
anything in the LilyPond source tree that would be related to it.
So the correct way is to continue _heeding_ GUILE_CONFIG when it is
given. If it stops being the _recommended_ way, we can heed it while
outputting a warning and stating the preferred way of achieving the same
purpose. If we want to be obnoxious, we can even turn this into a fatal
error.
But ignoring a previously working manner of configuring things and doing
something different: that's just asking for trouble.
I got tripped up and used an unintended version of libguile for a while
(this is likely where my doc-building performance disappeared). James
got tripped up and got it wrong even after I gave the basics of that
problem.
And we are both quite more intimate with LilyPond than the average
system integrator.
Is there anybody who recently built with a non-system version of
Guile-1.8 intentionally?
So please, can we stop pretending that anyone building LilyPond is a
perfect omniscient programmer?
--
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".
- config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", David Kastrup, 2020/03/06
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", Werner LEMBERG, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options",
David Kastrup <=
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", Werner LEMBERG, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", David Kastrup, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", Werner LEMBERG, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", Jonas Hahnfeld, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", Werner LEMBERG, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", David Kastrup, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", Jonas Hahnfeld, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", David Kastrup, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", Jonas Hahnfeld, 2020/03/07
- Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options", David Kastrup, 2020/03/07