Werner LEMBERG <[email protected]> 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".
