This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions


On Sun, Jul 27, 2003 at 08:01:05PM -0400, Phil Edwards wrote:
> On Sun, Jul 27, 2003 at 07:50:40PM -0400, Daniel Jacobowitz wrote:
> > On Sun, Jul 27, 2003 at 07:33:13PM -0400, Phil Edwards wrote:
> > > To be both safe and helpful, the configure script actually stores those
> > > variables into the generated config.status file -- pay attention now --
> > > as if they had been specified on the command line.  The shell variable
> > > which stores command-line arguments is augmented with those "precious"
> > > environment variables.
> > > 
> > > 
> > > So when a multilib run is fired off with configure generated by 2.57,
> > > the created primary config.status source's config-ml.in, which then does
> > > this just as before:
> > > 
> > >     Multilib=`echo Primary | sed '.....'`
> > > 
> > >     CXX=Multilib $srcdir/configure --stuff 'CXX=Primary'
> > > 
> > > When configure examines the command line and sees variable assignments,
> > > it performs them without examining the current environment.  It does this
> > > for safety, because it thinks the user is rerunning configure.
> > > 
> > > That sound you hear is configure wailing, "MY PRECIOUSSSSSSSS!" as it
> > > overwrites Multilib with Primary.
> > > 
> > > 
> > > I've made a couple of half-hearted attempts to defeat this from within
> > > libstdc++'s acinclude.m4, but autoconf is too smart for me.
> > 
> > Can't you just modify what config.status thinks the command line was,
> > at this point?  Either to correct Primary, or to append CXX=Multilib?
> > Presumably from within config-ml.in.
> 
> Correcting Primary is tricky without the toplevel knowing more about
> multilibs.  Appending CXX=Multilib would have to be done within config-ml.in,
> and I believe would work, but would also break all 2.13-style configures,
> which (IIRC) didn't understand env assignments as command-line arguments.

Is this code run once per subdirectory per multilib, or once per
multilib?  If the former we could just check which configure we're
passing off to.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]