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