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