This is the GN equivalent of build/java.gypi. It is a template for
creating an Android library including java code and Android resources.
It currently only compiles java files (including files in srcjars from
srcjar targets like java_cpp_template) and zips them together in a .jar
and creates the corresponding .jar.TOC.
Some of the things still to do: proguard_preprocess, android_lint,
emma coverage, dex, everything resources.
Adds android_java_library rule for base_java, guava, and jsr-305.
This add the --java-srcjars argument to javac.py. This will accept a .zip of
.java files and include those files in the compilation. This approach is
preferred over using the --src-gendirs option.
Many of the parts of building Android stuff (libraries, resources, apks)
require knowledge of the dependents of that thing. Examples: javac classpath,
for resources aapt needs to know about all dependents, dexing for an apk
needs to know about all java code going into that apk. For gyp, this is done
primarily with all_dependent_settings. There is then some of this logic in
two particular steps (dexing and proguard). These steps, when building an
instrumentation apk, need to exclude the things in the tested apk and this is
done by having the tested apk essentially write a file saying what it did in
those steps and the test apk reading that file and excluding stuff.
In GN, all_dependent_settings doesn't really work. This change introduces a new
way of calculating and using this information. Specifically .build_config files
and build_utils.ExpandFileArgs(). The build_config file for a target contains
the information that depends on dependents. The logic in write_build_config and
the logic in the template specification are very much tied together (in some
sense, write_build_config is just the part of the template specification
that can actually inspect the dependency graph). With
build_utils.ExpandFileArgs() all the other build scripts are essentially
unaware of the .build_config files and can just be written in a (mostly)
straightforward way.
A large part of the information calculated by the build_config is finding input
files to later actions. This requires that those later actions writes a depfile
that contains any inputs that are specified by the build_config (in the case of
this change, javac and the classpath files). Since a action's script shouldn't
really know about the build_config file and what information it got
from that, it is safest for the action to write *all* of its inputs into the
depfile (but to be correct it only has to write those that aren't explicitly
specified in the build files).
Depends on: https://codereview.chromium.org/341823003/
BUG=359249
Review URL: https://codereview.chromium.org/269943005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280995 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
9f9e39c561