In addition to searching the source directory for
.java
files,
SCons actually runs the .java
files
through a stripped-down Java parser that figures out
what classes are defined.
In other words, SCons knows,
without you having to tell it,
what .class
files
will be produced by the javac call.
So our one-liner example from the preceding section:
Java('classes', 'src')
Will not only tell you reliably
that the .class
files
in the classes
subdirectory
are up-to-date:
%scons -Q
javac -d classes -sourcepath src src/Example1.java src/Example2.java src/Example3.java %scons -Q classes
scons: `classes' is up to date.
But it will also remove all of the generated
.class
files,
even for inner classes,
without you having to specify them manually.
For example, if our
Example1.java
and
Example3.java
files both define additional classes,
and the class defined in Example2.java
has an inner class,
running scons -c
will clean up all of those .class
files
as well:
%scons -Q
javac -d classes -sourcepath src src/Example1.java src/Example2.java src/Example3.java %scons -Q -c classes
Removed classes/Example1.class Removed classes/AdditionalClass1.class Removed classes/Example2$Inner2.class Removed classes/Example2.class Removed classes/Example3.class Removed classes/AdditionalClass3.class
To ensure correct handling of .class
dependencies in all cases, you need to tell SCons which Java
version is being used. This is needed because Java 1.5 changed
the .class
file names for nested anonymous
inner classes. Use the JAVAVERSION
construction
variable to specify the version in use. With Java 1.6, the
one-liner example can then be defined like this:
Java('classes', 'src', JAVAVERSION='1.6')
See JAVAVERSION
in the man page for more information.