public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: meissner@cygnus.com
To: law@cygnus.com, robertl@dgii.com
Cc: egcs@cygnus.com, lmarasci@stevens-tech.edu
Subject: Re: Environment variable to pass in options?
Date: Mon, 08 Dec 1997 06:48:00 -0000	[thread overview]
Message-ID: <199712081447.JAA06165@tweedledumb.cygnus.com> (raw)

| > We already have a tough time getting all the information we need to
| > reproduce & fix problems.  Adding an environment variable of this
| > nature just makes things harder since someone could put options in
| > the environment variable, then forgot to tell us about them when
| > they report a bug.
| 
| SCO has had a similar feature in their tools for a long time.  You can
| stuff things in environmental flags or in /etc/default/cc.
| 
| I thoroughly hate this feature for the very reason Jeff describes.
| I have people constantly asking me "why does the compiler do XXX"
| and I spend a while beating on it and say, "it doesn't".   They
| send a test case and say, "does too".  I test their test case and
| say, "does not".   This is when they find out the system admin or
| some other coworker added '-Obazillion -UseSomeEsotericThing' to
| one of the above places and that's causing the wierdness.

Given that the .s file now contains a list of switches given, I really don't
see any difference between having a shell script called gcc that invokes the
driver with additional options and an environment variable.

I do think we should add an option:

	-foptions=<file>

that pulls options in from <file>.  The reason for this is there are systems
with limited space for passing arguments.  This comes up in the cygwin
discussions every so often.  It would be nice if ar and ld had similar options
(I've certainly been bitting on other systems in the past with small limits).

             reply	other threads:[~1997-12-08  6:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-12-08  6:48 meissner [this message]
  -- strict thread matches above, loose matches on Subject: below --
1997-12-07 13:35 Louis Marascio
1997-12-07 15:26 ` Weiwen Liu
1997-12-07 15:56   ` Louis Marascio
1997-12-07 16:45 ` Jeffrey A Law
1997-12-07 17:32   ` Louis Marascio
1997-12-07 17:45     ` Jeffrey A Law
1997-12-07 17:50       ` Louis Marascio
1997-12-07 19:12       ` Robert Lipe
1997-12-07 19:22         ` Louis Marascio
1997-12-07 20:11           ` Jeffrey A Law
1997-12-07 20:17             ` Louis Marascio
1997-12-07 20:24               ` Jeffrey A Law
1997-12-07 20:32                 ` Louis Marascio
1997-12-07 21:22                   ` Jeffrey A Law
1997-12-08 14:35                   ` Richard Henderson
1997-12-07 20:32           ` Mark Mitchell
1997-12-07 20:32             ` Louis Marascio
1997-12-07 21:02           ` Weiwen Liu
1997-12-07 21:07             ` Louis Marascio

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=199712081447.JAA06165@tweedledumb.cygnus.com \
    --to=meissner@cygnus.com \
    --cc=egcs@cygnus.com \
    --cc=law@cygnus.com \
    --cc=lmarasci@stevens-tech.edu \
    --cc=robertl@dgii.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).