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

[Mike Frysinger]

On Tuesday 03 February 2009 13:38:59 Mike Frysinger wrote:
> 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.

so are these changes going to be merged ?  or do i have to post an 
updated/complete patch first ?
-mike

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