Re: whither specs?

[Zack Weinberg <zack at codesourcery dot com>]

On Mon, Jun 10, 2002 at 10:29:14AM -0700, Geoff Keating wrote:
> 
> My recent patch to the driver allowed it to include target-dependent
> code.  Now that we no longer need to encapsulate all the
> target-dependent argument passing in a separate file, I think this is
> a good time to sit back and ask ourselves:
> 
> - Do we still want to have the 'specs' file in $(gcc_tooldir)?  It's
>   now redundant unless the user edits it, since the driver generated
>   it in the first place.  I guess the real question is, "do we want
>   to support the user changing this file?"  Is there a better way we
>   could support the functionality that people try to get by changing
>   this file?
> 
> - Do we want to keep supporting the -specs= command-line switch?  If
>   we could come up with another mechanism for the things that people
>   usually use this for, we could mark it as `obsolete' for GCC 3.2.
> 
> - Do we like to use specs internally?  I'm going to spend some time
>   this week designing a way to have the backends provide C code to
>   pass flags to the assembler, which should help with some of the more
>   horrible problems in this area; see, for instance, asm_cpu_spec in
>   rs6000.h.  Should this sort of thing be encouraged, or kept for
>   those situations where the alternative is too terrible to contemplate?

Neil had much of a driver rewrite done last year.  It got shot down on
the grounds that we still needed the ability to edit the specs after
installation.

Personally, I felt that the problems which people currently solve by
doing that, could and should be solved differently -- and that the
appropriate move would be to get rid of specs entirely, then fix the
problems that come up only when they do come up, case-by-case.

Witness how much of an improvement the TARGET_*_BUILTINS stuff is over
doing -D switches from the specs.  I'm confident that similar
improvements are out there if we do everything like that.

zw