[Top][All Lists]

[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


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

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

foo_JAVA =

compiles and 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

foo_JAVA = foo.jgroup
foo_jgroup_JAVA =

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

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

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

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

compiles with CLASSPATH pointing to Swing, then 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

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 =

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

Compiles and 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


 - 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 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?


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]