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:
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
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')
JAVAVERSION in the man page for more information.