[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3] configure: preserve various environment vari
Re: [Qemu-devel] [PATCH v3] configure: preserve various environment variables in config.status
Tue, 4 Sep 2018 11:21:05 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
On 09/04/2018 07:36 AM, Daniel P. Berrangé wrote:
The config.status script is auto-generated by configure upon
completion. The intention is that config.status can be later invoked by
the developer directly, or by make indirectly, to re-detect the same
environment that configure originally used.
The current config.status script, however, only contains a record of the
command line arguments to configure. Various environment variables have
an effect on what configure will find. In particular PKG_CONFIG_LIBDIR &
PKG_CONFIG_PATH vars will affect what libraries pkg-config finds. The
PATH var will affect what toolchain binaries and XXXX-config scripts are
found. The LD_LIBRARY_PATH var will affect what libraries are
found. Most commands have env variables that will override the name/path
of the default version configure finds.
All these key env variables should be recorded in the config.status script.
Autoconf would also preserve CFLAGS, LDFLAGS, LIBS, CPPFLAGS, but QEMU
deals with those differently, expecting extra flags to be set using
configure args, rather than env variables. At the end of the script we
also don't have the original values of those env vars, as we modify them
The latter half could be overcome by creating envvars named 'FOO_saved'
near the beginning of configure, if they prove important. I still find
it odd that we aren't precisely mirroring the (nice!) semantics that
autoconf users have come to rely on, but this is definitely a step
closer, and solves the immediate problem documented in the commit
message, so I see no reason to wait for even more complexity to be added
without a definite user of such complexity.
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Stefan Weil <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>
configure | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
Previously sent 3 (!) years ago:
Changed in v3:
- Added 'unset' code (Stefan)
- Clarify CFLAGS handling (Eric)
diff --git a/configure b/configure
index e7bddc04b0..718e89724a 100755
@@ -7518,6 +7518,46 @@ cat <<EOD >config.status
# Compiler output produced by configure, useful for debugging
# configure, is in config.log if it exists.
+ eval envval=\$$envname
+ if test -n "$envval"
We are not catering to the case where $envname is set but explicitly
empty (autoconf is able to track that case). However...
+ echo "$envname='$envval'" >> config.status
+ echo "export $envname" >> config.status
+ echo "unset $envname" >> config.status
+# Preserve various env variables that influence what
+# features/build target configure will detect
...of all of the variables we are marking precious (at least, that's the
terminology autoconf uses for this behavior), I seriously doubt anyone
would ever purposefully set the variable to empty with an expectation of
things working. So, we are safe in assuming that if a variable matters,
it is either not set or else set to a non-empty value.
Thus my R-b from years ago still holds.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org