This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Environment variable to pass in options?


| > 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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]