This is the mail archive of the
mailing list for the GDB project.
Re: GDB compile problem.
- To: Michael Elizabeth Chastain <chastain at cygnus dot com>
- Subject: Re: GDB compile problem.
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Date: Mon, 26 Feb 2001 17:06:21 +0200 (IST)
- cc: gdb at sourceware dot cygnus dot com
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
> 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
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''?