Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB compile problem.
Date: Mon, 26 Feb 2001 07:08:00 -0000	[thread overview]
Message-ID: <Pine.SUN.3.91.1010226165704.24373A-100000@is> (raw)
In-Reply-To: <200102261207.EAA04396@bosch.cygnus.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
> 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''?


  reply	other threads:[~2001-02-26  7:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-26  4:07 Michael Elizabeth Chastain
2001-02-26  7:08 ` Eli Zaretskii [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-02-26 10:47 Michael Elizabeth Chastain
2001-02-26 11:51 ` Eli Zaretskii
2001-02-25 22:55 Michael Elizabeth Chastain
2001-02-25 15:51 Michael Elizabeth Chastain
2001-02-25 15:15 Alex Turner
2001-02-25 21:31 ` Trond Eivind Glomsrød
2001-02-25 22:05   ` Alex Turner
2001-02-26  6:06     ` Trond Eivind Glomsrød

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SUN.3.91.1010226165704.24373A-100000@is \
    --to=eliz@is.elta.co.il \
    --cc=chastain@cygnus.com \
    --cc=gdb@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox