This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [PATCH] add GCC_OPTIONS


On Wed, Jun 25, 2003 at 11:10:11PM +0100, Joseph S. Myers wrote:
> On Wed, 25 Jun 2003, David O'Brien wrote:
> 
> > This patch takes an idea from GNU Grep and adds support for the
> > "GCC_OPTIONS" environmental variable.  This is *very* useful when one is
> 
> What is your answer to the problem of bug reports which give all the
> information requested but fail to mention the environment and so are not
> reproducable because of this option (which has been raised each time this
> idea has been suggested from time to time in the past)?

The world isn't perfect, and I really hope this won't be the reason used
to kill this patch.  That the need of it has come up multiple times shows
there is a need for it.

What's the answer to the problem of bug reports that any random gcc
option causes bad code to be generated, or the situation where the
compiler segfaults on a large propriety code base that can't be shared in
a bug report?

My suggestion would be for the person to add -v to their compiler
invocation.  What ever options are set in the environment will be clear
in the -v output.  Or in the instructions tell submitters to give the
output of "env" and/or "set" at their shell prompts.  You can't cover
every case of "hard to track down bug" -- the question is do you really
expect the use of this environment variable to "hide" the problem point
in > %5 of bug reports?  There already is the "hidden" problems due to
low ulimit values, etc.

 
> > Unfortunately the more direct "env CC='gcc -g' make" often doesn't work
> > as developers frightening often hard code "CC=gcc" in Makefiles, or worse
> > just use "gcc" directly in the target's build rules.
> 
> So use a wrapper "gcc" script earlier in the path.  Surely they are not
> hardcoding /usr/bin/gcc or similar?

I expected this response, and if the simplicity and cleanliness of using
"export GCC_OPTIONS=.... ; ./run-this-command" aren't seen, I don't know
what to say.  I find this cleaner and less problem prone than having to
create a script of the right name, and get it placed at the right point
in the search path -- especially if $* or $@ would be correct in the
script given what ever random -D's are specified by the Makefile for
gcc's invocation.

There are also times that one has to relink or recompile something as
part of a large software install.  Providing instructions for setting the
environment correctly is easier from a support stand point than trying to
get the user to correctly use a "gcc" wrapper script.

This patch is already part of the FreeBSD system compiler, and I quite
like being able to set options I always want to use, so that no matter
what CC setting I'm using (system compiler, later one from ports, earlier
one from ports), I get my preferred options.
 
-- 
-- David  (obrien@FreeBSD.org)


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