This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


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

Re: GDB compile problem.



On Mon, 26 Feb 2001, Michael Elizabeth Chastain wrote:

> chastain> After a couple of rounds of e-mail, we figured out the problem:
> chastain> on Alex Turner's system, there's an environment variable "CPP=g++".
> 
> eliz> Shouldn't that be "CXX=g++"?
> 
> Sorry, my grammar is contorted.

No, it wasn't: I understood exactly what you meant.  Perhaps my own 
wording was unclear, in which case it's my turn to apologize.

> So yes, it would be good for us if whatever *other* software that someone
> has on their system would use CXX and not CPP as an environment
> variable.
> 
> But it would be good if *our* software gave a useful error message:
> "you have something named CPP in your environment, but it does not
> perform the task of a C Preprocessor."

There's no end to this.  What if someone sets "CC=/not/a/compiler/at/all",
or "LN_S=/anything/but/ln"?  If that happens, the configury stuff will 
begin falling apart all over the place, with all kinds of weirdo error 
messages.  I think a line should be drawn somewhere, and using 
well-established variable names for incompatible purposes is IMHO beyond 
that line.

Moreover, these variables are there _precisely_ so the end-user could set 
them to whatever she pleases without being subject to Autoconf's 
scrutiny, for those cases where Autoconf isn't smart enough.  If you now 
let Autoconf have its own ideas about the values of these variables, you 
might as well screw somebody else.

PS. How do you even check that the preprocessor ``works''?


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