Re: [RFC] Suggested replacement for specs and switch handling

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Alexandre Oliva wrote:-

> I wonder if it would really be too costly to read in (a collection of)
> spec files in the format you or Zack propose at run-time, as opposed
> to compiler build time.  Then, we'd still keep the same run-time
> configuration abilities, but we'd have a far more user-friendly specs
> interface.  We could have pre-compiled specs for speed, if speed is a
> concern.

Yes, it would be.  This is half of the reason I'm doing it; if we
can't agree the new stuff is a good idea then I don't want to pour any
more time into it.  Note that with Bruce Korb's urging I'm considering
using Autogen to do the hashtable generation - that would allow a
really nice syntax for the configuration files, with help texts and
everything kept together with the option.  We really don't want an
autogen invocation for every GCC invocation :-)

> Some other items for the wishlist: in order to properly implement a
> portable -rpath/-R-like switch, it would be really nice to have some
> means to collect all occurrences of -R/-rpath in the command line and
> output a single colon-separated path to the linker, either in a
> command-line flag or in an environment variable.

This sounds easy, there's nothing different here to other rewriting we
need to do, e.g. splitting up -Wp, and suchlike.

> It would also be nice to be able to probe environment variables: for
> example, in case we decide to implicitly add the directory
> containing libstdc++.so to the search path of an executable being
> created, we must add it after any other -R/-rpath options given in
> the command-line; if none of these options are present, we should
> get a list of directories from LD_RUN_PATH.  I really hope this new
> spec-file format can be made rich enough to make this possible.

It doesn't sound to me like this needs to appear in the configuration
file.  Why can't it be done in gcc.c like everything else?

> Another issue is that of being able to install front-ends separately,
> each one with its own specs.

If we go with what I'm suggesting, "specs" disappear altogether, and
configuration is a build-time thing.

Neil.