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''?
next prev parent 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