automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Java roadmap


From: Simon Richter
Subject: Java roadmap
Date: Sat, 1 Mar 2003 05:19:13 +0100
User-agent: Mutt/1.5.3i

Hi,

now that the difficult part of my exams is over, I can start to think
about hacking Java support in automake.

Currently, when compiling Java files to bytecode, this happens with
"javac" (hardcoded, but can be overridden with an argument to make). The
class files are output to the build root dir, and the default install
rule copies all files matching *.class to the installation directory
(note that it works from the current dir -- only flat packages are
supported).

Since this interface is somewhat lacking anyway, keeping compatibility
isn't hard (if this is wanted). The proposed interface looks like this:

foo_JAVA = Foo.java Bar.java

compiles Foo.java and Bar.java and puts the resulting files into
$(foodir). In order to resolve circular dependencies, all files newer
that the timestamp are compiled in one go. The classpath for the
compilation contains just the output directory and the Java core
classes.

foo_JAVA = foo.jgroup Baz.java
foo_jgroup_JAVA = Foo.java Bar.java

compiles Foo.java and Bar.java together, Baz.java separately from the
other two. The compilation passes do not see each other's output (i.e.
you cannot see class Foo from Baz.java).

foo_JAVA = foo.jgroup
foo_jgroup_JAVA = Foo.java Bar.java
foo_jgroup_CLASSPATH = /usr/share/java/swingall.jar

compiles Foo.java and Bar.java as above, but adds swingall.jar to the
CLASSPATH for the compilation.

foo_JAVA = foo.jgroup
foo_jgroup_JAVA = Foo.java
foo_jgroup_CLASSPATH = bar.jgroup
bar_JAVA = bar.jgroup
bar_jgroup_JAVA = Bar.java
bar_jgroup_CLASSPATH = /usr/share/java/swingall.jar

compiles Bar.java with CLASSPATH pointing to Swing, then Foo.java with
CLASSPATH pointing to the temp dir where Bar.class resides in. Foo.class
and friends will be installed to $(foodir), Bar.class and friends to
$(bardir).

Of course, care will be taken to handle packages correctly, i.e. when
the compiler outputs stuff in subdirectories.

Archive creation will be the next step afterwards:

foo_ARCHIVES = foo.jar
foo_jar_JAVA = foo.jgroup
foo_jar_DATA = foologo.png
foo_jgroup_JAVA = Foo.java Bar.java

baz_JAVA = baz.jgroup
baz_jgroup_JAVA = Baz.java
baz_jgroup_CLASSPATH = foo.jar

Compiles Foo.java and Bar.java in one go, puts the resulting files
together with foologo.png in a new archive called foo.jar, then passes
this archive on the classpath when building Baz.java.

Limitations:

 - When passing .java files in the primary rather than with a group, it
   is not possible to specify a different classpath.
 - Since paths might not be known at Makefile.in generation time, it is
   assumed that @substitutions@ evaluate to objects outside of the build
   tree. No dependencies will be generated for them, as sometimes the
   classpath may be a directory, and make's behaviour when depending on
   directories is not properly defined.

.jgroup files are not meant to exist at any time, which makes the entire
interface a bit ugly. I haven't had a better idea yet, however.

To address: If a Java source is mentioned multiple times, should we try
to reuse the compilation result?

Do you think this is the right way to go?

   Simon

-- 
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4

Attachment: pgpUdiPGalLB8.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]