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



reply via email to

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