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

[Werner LEMBERG]

> 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