This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: RFC: micro-libgcj merge proposal
Joel Dice wrote:
* Add preprocessor directives to various native source files (*.cc) under
the libjava directory of the following forms:
#ifndef ULIBGCJ
... // code that should not be included in the micro-libgcj build
#endif
#ifdef ULIBGCJ
... // simplified version of code for micro-libgcj build
#else
... // full-featured and/or high-performance version for normal
// build
#endif
I expect this will be short-term - we will want finer-grained
configuration ability.
* Add a new subdirectory under libgjava called micro-libgcj which will
contain a separately-maintained set of Java files representing
micro-libgcj's classpath (a subset of java.lang.* and java.util.*).
Assume the micro-libgcj versions share a lot of code with the regular
versions, then it would be nice to generate the former from the latter.
I suggest using pre-processing as I suggested earlier. For example,
if we decide we don't want to support Class.getClassLoader:
/* #ifndef ULIBGCJ */
/** Use the classloader of the current class blah blah blah */
public static Class forName(String name) throws ClassNotFoundException
{
return VMClass.forName(...);
}
/* #endif */
You can then use my PreProcess tool (which I'm happy to donate)
to generate the micro-libgcj version of java/lang/Class.java.
This can be done at 'make' time, so you don't need to keep a
separate Class.java in CVS. (It might be best to manually
translate PreProcess.java in C or C++, to avoid convoluted
build logic, though we can also require that java be available
in the build environment when building micro-libgcj.)
To clarify: when you make micro-libgcj, it will create pre-processed
copies in a separate directory, before compiling that directory.
--
--Per Bothner
per@bothner.com http://per.bothner.com/