Re: [Bug-ed] [PATCH] configure: respect user env settings

[Mike Frysinger]

On Tuesday 03 February 2009 12:08:23 Antonio Diaz Diaz wrote:
> Mike Frysinger wrote:
> >>The "toolchain fix" is not a fix, but a step backwards. Specifying
> >>variables as arguments to configure helps to recreate the same
> >>configuration later with config.status even if the environment changes.
> >
> > and as i already pointed out, autotools (which is the "gold" standard for
> > configure scripts) respects the environment just fine, even with
> > config.status in use.  autoconf has no problem at all saving the state at
> > configure run into config.status for later usage.
>
> But your patch doesn't work because ed's configure doesn't save the
> environment to config.status for later use

well that's trivial to fix:
--- a/configure
+++ b/configure
@@ -173,6 +173,13 @@ if [ x${no_create} = x ] ; then
 # This script is free software: you have unlimited permission
 # to copy, distribute and modify it.
 
+CC="${CC}"
+CXX="${CXX}"
+CPPFLAGS="${CPPFLAGS}"
+CFLAGS="${CFLAGS}"
+CXXFLAGS="${CXXFLAGS}"
+LDFLAGS="${LDFLAGS}"
+export CC CXX CPPFLAGS CFLAGS CXXFLAGS LDFLAGS
 exec /bin/sh ${invocation_name} ${args} --no-create
 EOF
        chmod +x config.status

> Wouldn't be easier for all to always pass the variables as arguments to
> configure?

as already explained, the build system can "just work" and integrate trivially 
into the packaging systems that already exist, or you can force people to do 
something special for this one package.  working with the environment is much 
easier for package maintainers than custom configure arguments.
-mike

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