269553 - Integrate JavaXPCOM into build system

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: Packaging, defect)

Description

[jhp (no longer active)]

The JavaXPCOM code is checked into the trunk and working.  Now, I just need to
integrate it into the build, such that the appropriate IDL files are compiled
into Java class files and merged into a jar, and the JNI library built and
installed into DIST.

Comment 1

[jhp (no longer active)]

Attachment: preliminary patch

This is my initial patch.  Still needs some work, but I'm looking for input on
the direction I've taken here.

I have a custom version of xpidl here, that I've put in
extensions/java/xpcom/tools/xpidl.  Eventually, I'll probably end up creating a
custom util to compile the IDL files into .java files, but for now, I have this
version of xpidl working.

For the most part, I am only compiling the SDK_XPIDLSRCS files.  However, this
doesn't cover everything that is necessary to embed Mozilla, so in some
Makefiles, I've added specific files that are needed by Eclipse.  I probably
need to add some others, though.

The rules in rules.mk aren't perfect.  For one thing, since in Java you can
only have one public interface or class per file, java_xpidl will break apart
an IDL file with multiple interfaces.  In rules.mk, I have a rule for "%.java:
%.idl", but since there is no one-to-one correspondance, that rule is wrong. 
Any ideas on the best way to handle this situation?

Comment 2

[jhp (no longer active)]

Attachment: patch v1.1

1) Added some configure.in options for specifying the location of the Java
headers and of the Java programs.  If neither of these are specified to
configure, then it defaults to using $JAVA_HOME/include and $JAVA_HOME/bin. 
Uses these values to defined JAVA_INCLUDE_PATH, JAVAC, and JAR in autoconf.mk.
2) Due to the one-to-many relationship between IDL files and generated Java
files, I created a rule for a Java depency file (".{NAME}.java.pp") that
depends on the IDL file.  The side-effect of creating this dependency file is
to generate the Java interface and stub files.
3) Updated the extensions/java/xpcom/tests/Makefile.in to point to the correct
location now for the jar file.	Also, had to add nsIArray to JAVA_XPIDLSRCS, so
the test could run.  I could make this only when ENABLE_TESTS is set.  This
again brings up the question of which interfaces should be included in the jar
file, for use by Java embeddors.

I have another problem which I don't know how to solve.  The jar files (built
in extensions/java/xpcom/build) don't depend on anything.  So if any IDL file
is changed, or added or deleted from JAVA_XPIDLSRCS/SDK_XPIDLSRCS, the jar
files won't regenerate.

Comment 3

[jhp (no longer active)]

Attachment: patch v1.2

That last patch was not quite ready for prime time.  Changes in this patch:
- java_xpidl needs to be built after libxpt is built but before the first IDL
is processed.  So I moved the call to build extensions/java/xpcom/tools/xpidl
from the top level Makefile.in to xpcom/typelib/Makefile.in.  Maybe the best
solution for this is to call xpcom/typelib/Makefile.in in tier_0, so that any
language bindings that make use of libxpt and need to process IDLs could just
be appended to tier_0.	Any thoughts?
- Added entries in allmakefiles.sh for creating Makefiles.
- Added support for building in Win32 and Mac OS X (in addition to Linux).

Comment 4

[Benjamin Smedberg]

Comment on attachment 166512 [details] [diff] [review]
patch v1.2

Please move the "java paths" section of configure.in next to the other system
paths like MACOS_SDK_DIR. Otherwise, this looks great!

Comment 5

[jhp (no longer active)]

Checked into trunk.