integrated -save-temps and the death of specs

Stan Shebs shebs@apple.com
Tue Mar 19 17:36:00 GMT 2002


Aldy Hernandez wrote:
> 
> On Tuesday, March 19, 2002, at 09:41  PM, Richard Kenner wrote:
> 
> >     i got very upset at specs files today and decided to start the
> > painful
> >     process towards getting rid of them altogether.
> >
> > I think that would be a major step *backwards*.  The advantage of specs
> > file is that you can make changes to the way commands are called without
> > having to recompile anything.
> 
> the only good argument i have seen for spec files have been run-time
> changes to the driver-- ala, user level spec files.  vendor X wants
> to override defaults and link in different things when -mfoo is
> specified.  other than that, the benefits are too little for the
> amount of unmaintainability, not te mention-- spec files are close
> to undebuggable.

I haven't seen anybody mention the sometimes-goal of making the
driver independent of configury.  The theory is that one would
have a single driver program that would read specs files in order
to set itself up as a native Solaris, x-arm-elf, x-Cygwin, etc.
I've never seen this work out in practice though;  inevitably
each driver ends up with its own name (for the next OS X, we'll
have both 2.95 and 3.1 available, as "gcc2" and "gcc3"; the idea
of using -V to choose 2 vs 3 was on the table, but not for long).

A consequence of this is that gcc.c is not really set up to link
with different target-specific source code.  So for instance for
Darwin there are a bunch of unique linker flags and weird stuff
that would need to have its own source file distinct from the
code in config/darwin.c.  Not a fatal flaw, but something to keep
in mind.

> i agree that we have to provide a mechanism for user configurability,
> but not at the expense of unreadability.  who can argue that the spec
> file at the end of this message is readable, easy to update, and
> debuggable? (that's just a random one picked).

I must be an old fogey then - the spec string doesn't seem any
worse than the C code. :-)

Stan



More information about the Gcc-patches mailing list