Re: Supporting different runtime profiles

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:

Anthony> I'd like to introduce the notion of "profiles" to gcj.

Cool.  It looks like you've given this a lot of thought.

Anthony> * a profile, FOO, is built by reconfiguring gcc/libjava in
Anthony> the build directory gcc/$target/libjava/profiles/FOO.

I don't follow.  Is this something you do by hand?  Or is it something
you do once when you configure all of gcc?  E.g., with
--enable-libgcj-profiles=x,y,z?  How will mutlilibbing be handled?

Anthony> * the profile configury will have an opportunity to rewrite
Anthony> the configure options before configuration (to select an
Anthony> alternate GC or to disable threads, for instance).

I guess one thing that will be important is for us to identify the
necessary configuration points, and also to document how they
interrelate.  E.g., if you don't want reflection data, then you might
as well disable the interpreter and JNI.

Another thought that occurs to me is that we would want to test all
the configurations regularly, at least ot make sure that they build,
to ensure that we haven't let something slip past.

Anthony> * the headers are common accross all profiles.  Users will
Anthony> have to remember to use -Dgcj_profile_FOO when compiling C++
Anthony> code (hmm.. dunno how this works without touching files
Anthony> outside of libgcj/profiles/FOO)

This is the one piece that might not be implementable.
Maybe we could do it by putting a lot of work into gcjh.  It could
read every variant of a class and then output the appropriate header.
Given the current state of gcjh I'd guess that this would be a lot of
work.

Tom