From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: Michael Elizabeth Chastain Cc: gdb@sourceware.cygnus.com Subject: Re: GDB compile problem. Date: Mon, 26 Feb 2001 07:08:00 -0000 Message-id: References: <200102261207.EAA04396@bosch.cygnus.com> X-SW-Source: 2001-02/msg00363.html 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''?