Supporting different runtime profiles

[Anthony Green]

I wrote:
> I think our profiles will be something of a mix of Sun's J2ME
> `profiles' and `configurations'.  I'm curious if anyone else has
> thought about this in the context of gcj.

I spent a bit more time experimenting today and I thought I'd run this by
people before doing anything else...

I'd like to introduce the notion of "profiles" to gcj.  This is what Sun
calls different Java dialects and runtime configurations.  They've finalized
some profile definitions and are still working on others (through their
"community process").  Some example profiles are `foundation', `midp',
`personal', and `game'.  Not only do the class libraries change between
these different profiles, but the language can vary as well (no floating
point support, for instance).  For gcj, different profiles may have
different meta-data and object representations in addition to simple class
library changes.

Here are some of my thoughts:
    * the `default' libgcj is our equivalent to Sun's "Standard Edition"
(SE)
    * we'll always build and install the `default' libgcj, which attempts to
look as much like SE as possible... even in the absense of target
facilities, like networking support.
    * it should be possible to easily build and install support for multiple
profiles.
    * it should be possible to define and add profiles to gcc/libjava
without hacking the libjava configury and Makefile -- everything will be
local to a profile specific directory under gcc/libjava/profiles.
    * a profile, FOO, is built by reconfiguring gcc/libjava in the build
directory gcc/$target/libjava/profiles/FOO.
    * the profile configury will have an opportunity to rewrite the
configure options before configuration (to select an alternate GC or to
disable threads, for instance).
    * the profile configury also specifies a number of #defines which are
used when compiling C/C++ code, and for preprocessing Java source.
    * the profile configury includes a list of packages and classes to
exclude from the build, and new packages/classes to include.
    * each profile has its own spec file (or equivalent) for passing new
options to the compiler and selecting alternate libraries.
    * the specs file is installed as libgcj-FOO.spec.  Other installed files
are libgcj-FOO.jar and libgcj-FOO.{a,so}.
    * the headers are common accross all profiles.  Users will have to
remember to use -Dgcj_profile_FOO when compiling C++ code (hmm.. dunno how
this works without touching files outside of libgcj/profiles/FOO)
    * gcj will need an option like --profile=FOO for it to pick up
libgcj-FOO.spec, read libgcj-FOO.jar, etc.
.
Comments welcome....

AG