process_resources writes all inputs to a filelist, and then passes the md5sum
of the filelist as parameter (so that the commandline changes when inputs are
removed, causing a rerun).
Instead, just make the input filelist another input. gyp writes filelists when
their contents change, so this means if inputs are removed, the mtime of the
filelist will change, also causing a rebuild.
No intended behavior change.
BUG=177552
NOTRY=true
Review URL: https://codereview.chromium.org/199993003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257464 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
After r256667, the list of java files for javac is written into a gyp
filelist, which gets rewritten if a java file is removed. (If a generated
java file is removed, that still doesn't cause a rebuild, but that didn't
happen before this CL either, http://crbug.com/) This allows removing the
md5sum call for javac in java_apk.gypi.
java.gypi also has additional_input_paths as input, but that's only used
for stamp files, for ordering purposes, so it's not necessary to re-run
the javac action if a stamp file disappears from additional_input_paths.
With the same reasoning, the md5sum call in 'ant package resources' is not
needed: additional_input_paths is the only non-stamp input that isn't also
on the command line. ('ant package resources' is missing some inputs, but
that's independent of this change: http://crbug.com/351928)
No behavior change.
BUG=177552
R=cjhopman@chromium.org
Review URL: https://codereview.chromium.org/198283003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256746 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Before this CL, the javac action rules called `find javadir -name "*.java"` to
compute the action's inputs, and passed javadir to javac.py. The script then
again looked for all .java files in that directory. One issue with that approach
is that if a java file gets removed, the javac.py action didn't get executed again
since actions are only run if their commandline changes or an input file is newer
than an output file – a disappearing input doesn't mark an action dirty. (As
workaround, the md5 hash of all .java files is currently passed in an
--ignore parameter, so removal of a java file will lead to a changing
commandline, which _will_ cause a rebuild.)
After this CL, the result of `find javadir -name "*.java"` is written to a gyp
filelist (see https://codereview.chromium.org/27418008/), and the filelist
is passed to javac.py. gyp writes filelists exactly if their contents would
change, so removal of java file will change the mtime of the filelist, which will
cause a rebuild. Another advantage is that the list of java files is computed in
only one place.
This CL doesn't yet remove the md5 hack, but it makes it possible to do so
in a follow-up change.
(This approach doesn't work for generated java files, because these might
not yet exist at gyp time. Rename --src-dirs to --src-gendirs and keep it in
use for generated files. The dependency handling of generated java files is
done through stamp files, so the md5 hack isn't needed for them.)
No intended behavior change.
BUG=177552
R=cjhopman@chromium.org
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=256097
Review URL: https://codereview.chromium.org/193693002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256667 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Breaks target device_extras_apk on the upstream bot, due to the src/ issue
mentioned on the review: A java target contains another java target in a
subdirectory, and due to the missing src/ the java files in the subtarget
get picked up twice.
> android: Pass (non-generated) .java files via a gyp filelist to javac.py
>
> Before this CL, the javac action rules called `find javadir -name "*.java"` to
> compute the action's inputs, and passed javadir to javac.py. The script then
> again looked for all .java files in that directory. One issue with that approach
> is that if a java file gets removed, the javac.py action didn't get executed again
> since actions are only run if their commandline changes or an input file is newer
> than an output file – a disappearing input doesn't mark an action dirty. (As
> workaround, the md5 hash of all .java files is currently passed in an
> --ignore parameter, so removal of a java file will lead to a changing
> commandline, which _will_ cause a rebuild.)
>
> After this CL, the result of `find javadir -name "*.java"` is written to a gyp
> filelist (see https://codereview.chromium.org/27418008/), and the filelist
> is passed to javac.py. gyp writes filelists exactly if their contents would
> change, so removal of java file will change the mtime of the filelist, which will
> cause a rebuild. Another advantage is that the list of java files is computed in
> only one place.
>
> This CL doesn't yet remove the md5 hack, but it makes it possible to do so
> in a follow-up change.
>
> (This approach doesn't work for generated java files, because these might
> not yet exist at gyp time. Rename --src-dirs to --src-gendirs and keep it in
> use for generated files. The dependency handling of generated java files is
> done through stamp files, so the md5 hack isn't needed for them.)
>
> No intended behavior change.
>
> BUG=177552
> R=cjhopman@chromium.org
>
> Review URL: https://codereview.chromium.org/193693002TBR=thakis@chromium.org
Review URL: https://codereview.chromium.org/194293002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256127 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Before this CL, the javac action rules called `find javadir -name "*.java"` to
compute the action's inputs, and passed javadir to javac.py. The script then
again looked for all .java files in that directory. One issue with that approach
is that if a java file gets removed, the javac.py action didn't get executed again
since actions are only run if their commandline changes or an input file is newer
than an output file – a disappearing input doesn't mark an action dirty. (As
workaround, the md5 hash of all .java files is currently passed in an
--ignore parameter, so removal of a java file will lead to a changing
commandline, which _will_ cause a rebuild.)
After this CL, the result of `find javadir -name "*.java"` is written to a gyp
filelist (see https://codereview.chromium.org/27418008/), and the filelist
is passed to javac.py. gyp writes filelists exactly if their contents would
change, so removal of java file will change the mtime of the filelist, which will
cause a rebuild. Another advantage is that the list of java files is computed in
only one place.
This CL doesn't yet remove the md5 hack, but it makes it possible to do so
in a follow-up change.
(This approach doesn't work for generated java files, because these might
not yet exist at gyp time. Rename --src-dirs to --src-gendirs and keep it in
use for generated files. The dependency handling of generated java files is
done through stamp files, so the md5 hack isn't needed for them.)
No intended behavior change.
BUG=177552
R=cjhopman@chromium.org
Review URL: https://codereview.chromium.org/193693002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256097 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When the list of implicit inputs of a build edge shrinks, ninja doesn't
rerun it. The Android build uses complex build actions (e.g. ant) whose
output depend on directory contents and whatnot, and the Android build
by adding "dir/*.java" or similar as implicit inputs. So it's important
that ninja does rerun these actions when their list of implicit inputs
shrinks. As a workaround, the Android build passes the md5 of the list of
implicit inputs as "--ignored" parameter to the build action (ninja does
rerun edges whose commandline changes.)
Due to copypasta, this --ignored flag is used in a few places where it's
not actually used (on edges where all inputs are already passed as regular
commandline parameters).
Also remove the --ignored parameter from proguard.py as nothing passes it
any more.
BUG=177552
NOTRY=true
Review URL: https://codereview.chromium.org/175683005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@254414 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This adds a build step to generate mirrored images for use in
right-to-left (RTL) languages. Images are mirrored by flipping the
original image over the vertical axis. Every image must be explicitly
listed as mirrorable or non-mirrorable in a config file.
The goal: ensure that our RTL image assets are always up-to-date.
BUG=290225
NOTRY=true
Review URL: https://codereview.chromium.org/106173002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@243332 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The hash is calculated for the list of the resource files to determine if the
files were changed (added, removed, renamed, etc). The current way of doing it
may explode the command line length over the system limit. To avoid it, the list
of the input files is written to a temporary file on disk and the file is used
to calculate the checksum.
BUG=177552
R=cjhopman@chromium.org, newt@chromium.org
Review URL: https://codereview.chromium.org/20313002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@213849 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Currently, we are generating v14 layout and style resources from v17
resources by replacing Start and End attributes to Left and Right
attributes. However, it is not necessary for all cases, so make an
option to disable generate_v14_compatible_resources.py script and
only verify that there is no RTL attributes in the pre-v17 resources.
BUG=247049
Review URL: https://chromiumcodereview.appspot.com/18653002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@210555 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Gyp supports only very limited ways of changing behavior based upon
CONFIGURATION_NAME. Particularly, it does not support the way that was
supposed to enable/disable use of proguard.
Instead of trying to switch behavior in gyp, instead pass
CONFIGURATION_NAME, proguard_enabled, and
proguard_enabled_dex_input_path to dex.py and switch the behavior
there.
This also extracts the dex actions into build/android/dex_action.gypi
and uses that for the actions in both build/java.gypi and
build/java_apk.gypi.
BUG=240837
Review URL: https://chromiumcodereview.appspot.com/15231006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200958 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
There are several attributes introduced in API 17, mostly for BiDi(RTL) support, e.g., paddingStart.
This build script will generate another set of resource that is API 14 compatible by
converting those API 17 attributes to API 14 attributes, e.g., paddingStart -> paddingLeft.
The goal of this script is for programmers to use those attributes without worrying
about backward-compatibility care and related bugs. About the bugs, please refer to crbug.com/235118 .
BUG=235118
Review URL: https://chromiumcodereview.appspot.com/14476011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@198325 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The native component build creates .TOC files for each of the native
libraries. These files contain the compile-time visible API of the
corresponding library. That is, if something changes in the native
library that could have an effect on linking of dependent libraries,
then that change will be reflected in the .TOC file. Then, these .TOC
files can be used to determine if linking of dependents is required.
This change brings that same magic to Java.
When building a .jar, we also create a .jar.TOC that includes the
signatures for public/protected classes/functions/variables (including
the values for constants since they can be inlined dependents).
When compiling a Java library, use an Md5Checker over the .java files
and the classpaths .jar.TOC (using the .jar if the .TOC isn't available
as is currently the case for prebuilt jars).
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/14203002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@194080 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Some commands that are called by build scripts are particularly verbose
(ant, dex, readelf). For these commands, the output (when successful)
is not useful (unlike javac, for example). Add an option
(suppress_output) to build_util.CheckCallDie to disable printing of
stdout/stderr when the call is successful.
Also, move remaining build scripts in build/android to
build/android/gyp.
NOTRY=true
Review URL: https://chromiumcodereview.appspot.com/13473017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192409 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Some build steps, particularly javac, have really loose input rules.
I.e. javac steps are re-built when any input jar changes. Often, this
leads to unnecessary rebuilds of all the following steps.
Other build tools (ninja, goma), will check the contents of the inputs
to a step, and if those inputs haven't changed that tool doesn't
actually re-run the command for creating the output.
This change brings that same benefit to some of the Android python
build scripts. Particularly those that will save a significant amount
of time by adding input content checks.
The checking checks both the input files and the command that will be
run. It compares this against a stored md5 digest. If it has not
changed, then the output does not need to be recreated (though it is
still touched to trigger following steps).
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13432002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192265 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
For the component build, it is impractical/impossible to explicitly
list all library dependencies. This list is required (in dependency
order) for several of the apk-building steps.
For now, we will generate this list as follows:
Use readelf to find all transitive dependencies
Topologically sort those dependencies
Once we can expose this information from gyp
(http://crbug.com/2255588), it is straightforward to update this action
to use the gyp-exposed list of libraries.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13261024
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192103 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Libraries could previously access dependencies' resources in Java code
but not in XML layout files. This enables accessing these resources in
layout files as well, with the compromise that resources can now be
accessed using the wrong package name in Java code. Since resource
names are global anyway (an APK can't contain two resources with the
same name), this is deemed OK.
BUG=176069
Review URL: https://chromiumcodereview.appspot.com/13107002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@190896 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This enables Android layouts and Java code to use strings from
generated_resources.grd directly. Strings tagged with
formatter_data="android_java" in generated_resources.grd are used to produce an
Android strings xml file.
BUG=176069
Review URL: https://chromiumcodereview.appspot.com/12529025
git-svn-id: http://src.chromium.org/svn/trunk/src/build@190573 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
r188747 didn't actually fix the webview build problem (though it's still
a useful refactoring) - the right fix is just to add quotes to the
expansion in java.gypi such that the shell doesn't try to expand make
variables.
BUG=
Review URL: https://codereview.chromium.org/12917008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@188760 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is a fairly straightforward translation of the ant build script
into two python actions.
Two things have been moved into the gyp file: adding android.jar to the
classpath and specifying the jar_excludes (currently just R.class and
R$*.class).
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/12853002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@188594 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This appends the list of inputs to the ant and process_resources.py
commands. Thus when the list of inputs changes, the command line
changes, and ninja will re-run the command.
This will be removed once ninja is updated to automatically rebuild
when the input list changes.
BUG=177449,177552
Review URL: https://chromiumcodereview.appspot.com/12379066
git-svn-id: http://src.chromium.org/svn/trunk/src/build@186299 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We were using package_name as a unique name for naming output files and
directories. package_name was typically the same as _target_name or a
variation of it (like dropping _apk). Using _target_name instead means
we need to specify one less thing and it is (maybe?) guaranteed to be
unique.
TBR=brettw,joi,jar,fischman,zea,sky
BUG=
Review URL: https://chromiumcodereview.appspot.com/11308030
git-svn-id: http://src.chromium.org/svn/trunk/src/build@183639 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This generates localized strings.xml files (e.g.
values-fr/strings.xml) from grd and xtb files at build time. This
means we no longer need to check in localized strings.xml files. Note:
the xtb files are empty until translations are available.
Benefits:
- 41 fewer extraneous results when grepping Java string IDs
- Switching from maintaining strings in strings.xml over to using a
grd file is One Trivial CL* away: just include English in the list
of languages for which we generate strings.xml files.
*Restrictions may apply
Originally landed as https://codereview.chromium.org/11659006/
This can be re-landed as of https://codereview.chromium.org/11880050/
BUG=167248
TBR=yfriedman@chromium.org,thakis,jam@chromium.org,cjhopman,shashishekhar@chromium.org
Review URL: https://codereview.chromium.org/11967005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@177170 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Some fixes included:
- Changes to resource management to account for new R.java packaging
from library projects
(https://android-review.googlesource.com/#/c/43134/).
- Fixed the package for some inludes in ModalDialogTest.java. This only
worked because of how we previously used to aggregate all resoures
from the prior layer. With the new packaging, we must use the resource
from the appropriate layer.
BUG=163001,166434
NOTRY=true
Review URL: https://chromiumcodereview.appspot.com/11819047
git-svn-id: http://src.chromium.org/svn/trunk/src/build@176176 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
> [Android] Generate localized strings.xml files at build time.
>
> This generates localized strings.xml files (e.g.
> values-fr/strings.xml) from grd and xtb files at build time. This
> means we no longer need to check in localized strings.xml files. Note:
> the xtb files are empty until translations are available.
>
> Benefits:
> - 41 fewer extraneous results when grepping Java string IDs
> - Switching from maintaining strings in strings.xml over to using a
> grd file is One Trivial CL* away: just include English in the list
> of languages for which we generate strings.xml files.
>
> *Restrictions may apply
>
> BUG=167248
>
> Review URL: https://codereview.chromium.org/11659006TBR=newt@chromium.org
Review URL: https://codereview.chromium.org/11820058
git-svn-id: http://src.chromium.org/svn/trunk/src/build@176151 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This generates localized strings.xml files (e.g.
values-fr/strings.xml) from grd and xtb files at build time. This
means we no longer need to check in localized strings.xml files. Note:
the xtb files are empty until translations are available.
Benefits:
- 41 fewer extraneous results when grepping Java string IDs
- Switching from maintaining strings in strings.xml over to using a
grd file is One Trivial CL* away: just include English in the list
of languages for which we generate strings.xml files.
*Restrictions may apply
BUG=167248
Review URL: https://codereview.chromium.org/11659006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@176134 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This generates the copy of R.java used to compile the library jar (formerly
done in gyp) and adds a new step to crunch image resources.
The imaging crunching step fixes the link preview 9-patch drawing artifact,
among other benefits.
BUG=163602
Review URL: https://codereview.chromium.org/11516024
git-svn-id: http://src.chromium.org/svn/trunk/src/build@172655 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This provides support for android-style resource folders in content and other
non-apk Java targets. The AppResource hack can then be removed shortly.
Details: while building a non-apk target (e.g. chromium_content.jar), we
generate an R.java file with non-final constants and in the appropriate Java
package (e.g. org.chromium.content.R) using the resources in the target (e.g.
content/public/android/java/res). This R.java is used to produce the jar, but is
not included in the jar itself.
When we later build an apk, we merge the resources from the apk (e.g.
org/chromium/content_shell/res) with the resources from the non-apk targets it
depends on (e.g. content/public/android/java/res). A new R.java is generated
using the merged resources with the correct mapping from resources to integer
IDs. This R.java file is copied into each needed package (e.g.
org.chromium.content.R and org.chromium.content_shell.R) and included in the
apk.
This is the first of three CLs to replace AppResource with R:
1. http://codereview.chromium.org/11363150 - Support Java resources within content
2. http://codereview.chromium.org/11360207 - Add Java resources to content and chrome
3. http://codereview.chromium.org/11377117 - Remove AppResource and unneeded resources
BUG=136704
Review URL: https://codereview.chromium.org/11363150
git-svn-id: http://src.chromium.org/svn/trunk/src/build@168283 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The cacheinvalidation_java target is also added to build/all_android.gyp to
ensure it is always built since nothing currently depends on it upstream.
When all of Android-specific sync code is upstreamed, a target for sync
should be used instead of cacheinvalidation.
BUG=158382
Review URL: https://chromiumcodereview.appspot.com/11146005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@167746 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
thakis@chromium.org
newt@chromium.org
frankf@chromium.org
gkanwar@chromium.org
cjhopman@chromium.org
avayvod@chromium.org
andrewhayden@chromium.org
kkimlabs@chromium.org
yfriedman@chromium.org
boliu@chromium.org
torne@chromium.org
smckay@chromium.org
nyquist@chromium.org