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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Neil" == Neil Booth <neil@daikokuya.demon.co.uk> writes:

>> gcj currently depends on this this feature.  We create a spec file at
>> libjava configure time based on various target considerations.  Check out
>> libjava/libgcj.spec.in.

Neil> This is what Michael brought up as the disadvantage, though rth,
Neil> Mark and others thought it shouldn't get in the way of something
Neil> else if it were more maintainable.

I would prefer it if we considered what gcj needs as requirements for
any rewrite.  I think maintainability is important, but I also think
it is important that the feature set reflect all languages, and not
just C and C++.

Right now libgcj makes a `libgcj.spec' file which is read at startup.
It specifies all the default libraries that a user will need at link
time.  We do this because the list of required libraries is long, will
get longer, and is of no interest to the user.  Requiring a gcj user
to specify this would be like having a C user specify `crt0.o -lc
crtend.o', or whatever, at every link.

We also use libgcj.spec to pass required options to gcj itself.  We do
this because certain options affect the ABI and are compiled in to
libgcj itself.  Sinc the user is required to give them, and since
turning them off is simply wrong, we put them into the spec file.  In
theory this could be done by putting the options into gcj itself, but
in practice the method we've chosen seems simpler.  For one thing
there isn't an administrative overhead for each change -- no Java
developer can change gcc/configure.in without approval, but we can all
change libjava/configure.in however we like.  Also, putting this sort
of configury code close to libjava seems to make more sense
conceptually.

Finally, gcj does a lot of command-line rewriting in
gcc/java/jvspec.c.  For instance when `--main' is given we add new
specs to run `jvgenmain' and then `cc1'.  This code is fairly ugly,
but the functionality is required.  Be sure to look at the "combine
inputs" code (which I don't understand myself).  This code does
something that gcj does that none of the other front ends can do: it
invokes jc1 a single time on all its input files.  This is a
substantial compile-time performance improvement, and is pretty much a
standard in the Java world.

Tom