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

[Geoff Keating <geoffk at geoffk dot org>]

Tom Tromey <tromey@redhat.com> writes:

> 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.

I agree that the compiler should do this.  Couldn't this be done by,
for instance, writing a short textfile that just contains a list of
additional libraries, or by building the gcj driver after libgcj has
configured?

> 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.

This really sounds to me like a workaround to avoid deficiencies of
the approval procedure.  It would be better to reduce the
administrative overhead and produce a better compiler.

-- 
- Geoffrey Keating <geoffk@geoffk.org>