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: Jonas Hahnfeld
Subject: Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"
Date: Sun, 08 Mar 2020 10:57:13 +0100
User-agent: Evolution 3.34.4

Am Samstag, den 07.03.2020, 23:20 +0100 schrieb David Kastrup:
> Werner LEMBERG <
> address@hidden
> > writes:
> 
> > > I have no beef with deprecating it.
> > 
> > What about the following route?  For guile, I would add support for
> > `guile-config`, using the following algorithm (with item 1 already
> > implemented).
> > 
> >  1. Search for a guile `.pc` file, checking whether version 1.8.x,
> >     2.2.x, or 2.0.x is present (in this order).
> > 
> >     If a specific guile version is needed, set the `GUILE_FLAVOR`
> >     environment variable, for example
> > 
> >       ./configure GUILE_FLAVOR="guile-2.2"
> > 
> >     (possible values for `GUILE_FLAVOR` are `guile-1.8`, `guile-2.0`,
> >     `guile-2.2`, and `guile-3.0`).  If you want to use guile-3.0, you
> >     currently *must* use `GUILE_FLAVOR`.
> > 
> >  2. If nothing is found, try to execute `guile-config` (which must be
> >     in the path) to get the necessary compilation and linking flags.
> 
> The real problem case is not where nothing is found.  The real problem
> case is where the wrong version is found, GUILE_CONFIG is ignored, and
> the user is not notified.  So assuming GUILE_CONFIG is set, that should
> be tried in preference to a .pc file, giving a warning (an error would
> be a nuisance when trying to have a common configuration for both 2.20
> and 2.21, a consideration that will not really be relevant any more for
> 2.22 and 2.23).
> 
> >  3. Abort if this fails, too.
> 
> If I understand correctly, pkg-config is used for a number of
> packages/libraries.  So a selection mechanism/scheme that is not
> specific to Guile for adding pkg-config directories and selecting
> specific versions of specific packages seems like a reasonable idea as
> that would also enable selecting/pinning specific versions of, say,
> Freetype.

I don't think other projects do this and I'm against inventing new
solutions that others don't deem necessary. Our build system already is
too complicated because of past decisions like this.

> I'll try cooking something generic enough up that is also a reasonable
> candidate for being listed in ./configure --help as well as the
> installation instructions.

The following prints an error and directs the integrators into the
right direction:
diff --git a/configure.ac b/configure.ac
index 29e4e5680f..80a34f7b09 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,11 @@ STEPMAKE_MSGFMT(REQUIRED)
 STEPMAKE_TEXMF(REQUIRED)
 STEPMAKE_TEXMF_DIRS(REQUIRED)
 
+# For compatibility with previous releases.
+if test -n "$GUILE_CONFIG"; then
+  AC_MSG_ERROR([Non-empty GUILE_CONFIG detected, support has been removed.
+The new interface uses pkg-config. Please check that configure finds the right 
version. If needed, set PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR.])
+fi
 STEPMAKE_GUILE_DEVEL(REQUIRED)
 
 # check for 3 typedefs added in Guile 1.9

For listing in ./configure --help we should take Werner's update of
PKG_CHECK_MODULES.

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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