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: [RFC] Suggested replacement for specs and switch handling


On Wed, Jun 27, 2001 at 06:59:38PM +0100, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > A branch may be a good idea here.
> 
> I was never intending to bang around a big patch.  I was thinking of
> conditionally compiling it into gcc.c, and enabling it a target at a
> time. 

That could be very messy.

On the other hand, a variant of that idea might work: put the new
driver in a new file (gccdriver.c?) and put conditional Makefile
parameters set by config.gcc.  This is similar to how we developed
cpplib.  It also encourages us to recycle as little as possible of the
mess that is gcc.c.

...
> > I'd like to squash any suggestion of shell script wrappers right here
> > and now.  For one thing, you can forget any performance improvement.
> > For another, the Bourne shell is rather bad at argument lists,
> > especially if they have "interesting" characters in them - and the
> > list of "interesting" characters is much too large.
> 
> My understanding of a shell script wrapper was not for the normal case
> we all use, but for the case where the embedded guys wanted to change
> a customer's default invocation after shipping a compiler to them.
> But I may have misunderstood.

Well, see, I would like to avoid making people do that, too, if at all
possible.  It is something that can be dealt with later.

Someone suggested "response files", which could be a good model, at
least.  They're rather similar to my proposal for custom drivers.

I get the impression that most of the run-time configurability issues
are more in the line of flipping default settings of switches, than
completely re-jiggering the command line the way specs can
(theoretically) do.  And that's easy enough to handle.

> > You realize that that is going to be a huge vector.
> > 
> > If it can replace a bunch of the global variables currently being set
> > from the command line, however, that won't be a problem.
> 
> You can't be serious - it's less than 1,000 bytes!  We have about 750
> switches at present, and under 500 groups.  Each element in the vector
> is an unsigned short, i.e. 2 bytes - this was deliberate, to cut down
> the space.  The allocation is temporary too - we free everything once
> the switches have been interpreted.

You're right, I didn't have a good handle on the size of the vector.
My only impression of how many switches there are is the user's
"enough that --help has to be fed to a pager".

> I'm going to want to know whether my proposal (with modifications like
> using Autogen instead of hand-parsing, and splitting stuff out on a
> per-front-end basis) has a good chance of being accepted before I
> spend any more time on it, or think about creating a branch.

It's not for me to approve any such patch, but the project does have
my support, for what that's worth.

-- 
zw         > Having been converted to bagels in the US, ...
           Good Lord! You must have -really- offended a Jewish wizard.
           	-- Niall McAuley and Kip Williams in rec.arts.sf.fandom


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