Re: Two problems for autoconf(1.NEC SX 2.Cray)

[Paul Eggert]

> From: Jeroen van den Muyzenberg <address@hidden>
> Date: Fri, 22 Feb 2002 20:18:54 +1100 (EST)

> > In this case it appears to me that configure is doing the right thing.
> > If -g changes the semantics of the compiler, then a default build should
> > not use -g.
> 
> The use of -g to a compiler is often the only "first clue" to porting an
> app to a "non-standard" architecture. If possible it shouldn't be thwarted
> at the autoconf stage.

We are only talking about the default heuristic here.  You can
override the heuristic by setting CFLAGS in the environment.

I don't see why the default heuristic is incorrect here.  As far as I
can tell, the generated code runs correctly, and (presumably) is
optimized more than it would be without -g.  That's a reasonable
default.  The default heuristic can't be perfect, and it doesn't have
to be perfect; it only has to be reasonable.

> Seems to me that there has been a great deal of effort into dealing with
> "brain-damaged" compilers. Why stop now?

Because the code is working now.  In the case of the other compilers I
mentioned, the resulting code didn't work.

> > > there is no environment variable specification allowed for sed.
> >
> > Yes there is: you can set PATH so that the 'sed' you want is first in
> > the path.
> 
> This suggestion is not viable, changing PATH will also remove references
> to too many other utilities.

You can create a directory that has only 'sed' in it, and prepend that
to your PATH.  That won't change any other utility.

A better fix in this case is to fix your package's aclocal.m4 or
whatever so that it uses only portable sed commands.  But if you can't
do that for some reason, you can work around the glitch by setting
PATH.