This fills out a number of ui targets and does some changes to the resources to match the GYP build. In particular, we had a number of different ui/resources targets that were depended on independently. The GYP build has only one, so I combined them into a meta "ui/resources" target.
Adds a grit repack template.
TBR=ajwong
Review URL: https://codereview.chromium.org/369603004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@281087 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
components/autofill
components/metrics
components/policy
components/variations
third_party/libphonenumber
third_party/mt19937ar
ui/gfx/ipc
These are all requried to compile chrome/browser in some form or another.
Fills out all grit_defines (also required for chrome/browser) and adds associated flags for them.
Add the ability for generated_extensions_api to not generate a bundle.
Remove mt19937ar from .gitignore (it's just checked into the tree)
R=ajwong@chromium.org
Review URL: https://codereview.chromium.org/365793002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@281057 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
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
Reason for revert:
Linux dbg builder runs out of memory
Original issue's description:
> Adding -g3 to get macro expansion support. (Default is -g2.)
> Adding -gdwarf-4 for macro expansion support.
>
> * gcc 4.6 outputs DWARF-2 by default
> * gcc 4.7 outputs DWARF-4 by default
> * clang <3.4 outputs DWARF-3 by default
> * clang >3.4 outputs DWARF-4 by default
>
> From http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> > -g3
> > Level 3 includes extra information, such as all the macro
> > definitions present in the program. Some debuggers support macro
> > expansion when you use -g3.
> >
> > -gdwarf-4
> > Produce debugging information in DWARF format (if that is
> > supported). The value of version may be either 2, 3 or 4; the
> > default version for most targets is 4. Note that with DWARF
> > Version 2, some ports require and always use some non-conflicting
> > DWARF 3 extensions in the unwind tables.
> >
> > Version 4 may require GDB 7.0 and -fvar-tracking-assignments for
> > maximum benefit.
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257944
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=280980TBR=mark@chromium.org,mithro@mithis.com,thestig@chromium.org
NOTRY=true
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/366963002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280986 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adding -gdwarf-4 for macro expansion support.
* gcc 4.6 outputs DWARF-2 by default
* gcc 4.7 outputs DWARF-4 by default
* clang <3.4 outputs DWARF-3 by default
* clang >3.4 outputs DWARF-4 by default
From http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> -g3
> Level 3 includes extra information, such as all the macro
> definitions present in the program. Some debuggers support macro
> expansion when you use -g3.
>
> -gdwarf-4
> Produce debugging information in DWARF format (if that is
> supported). The value of version may be either 2, 3 or 4; the
> default version for most targets is 4. Note that with DWARF
> Version 2, some ports require and always use some non-conflicting
> DWARF 3 extensions in the unwind tables.
>
> Version 4 may require GDB 7.0 and -fvar-tracking-assignments for
> maximum benefit.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257944
Review URL: https://codereview.chromium.org/198363002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280980 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
These deps are some of those required to compile chrome/browser (so mostly those containing resources and protobufs that have generated headers). chrome/browser still has some dependencies left.
Add third_party libs libaddressinput and dom_distiller_js.
Add components dom_distiller and policy.
Separate the generate_library_loader into a separate .gni file.
Rename components_strings to just strings.
R=ajwong@chromium.org
Review URL: https://codereview.chromium.org/362583002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280916 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
generate_v14_compatible_resources.GenerateV14Resources was deleting and
recreating the output directory. process_resources was calling that
multiple times and reusing the same output directory (and so it would
only actually get v14 resources for the final directory).
Instead, callers of GenerateV14Resources should handle deleting/creating
the output directory for themselves--this is just
generate_v14_compatible_resources.main and process_resources (which was
already handling this itself).
BUG=383803
Review URL: https://codereview.chromium.org/362543004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280725 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This adds a lot of global enable flags for various features used by the browser.
It is not turned on because it does not compile yet. It needs some include directories and generated sources from dependencies that aren't done yet.
It is basically a line-by-line translation of the current chrome_browser.gypi. As such, it looks pretty ugly but I think keeping these in sync will be easiest.
I put in the obvious names of the GN deps. There are surely a bunch that exist in the GN build that aren't here yet but I'm going to save this for later passes.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/356303002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280693 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Sometimes the output of addr2line is ambiguous, example:
unicode.cc:0
and does not include the absolute path of the source file. This fix
is mostly a port of andrewhaydens solution to disambiguate the path.
BUG=
Review URL: https://codereview.chromium.org/339853004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280303 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This package makes avconv available which is used by Telemetry benchmarks to
decode mpg video captures from Android devices into Bitmaps which can be
processed frame-by-frame.
Installing this package allows the benchmarks to work on the bots.
BUG=388910
Review URL: https://codereview.chromium.org/339183012
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280208 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The only difference is that ChromeVox is flattened and compressed from
the individual source files instead of taken froma closure compiled version
from upstream. Deleting the precompiled js binaries and removing support
for using that version will be done in a follow-up cl when this has
been used on canary/dev for a while.
BUG=371692
Review URL: https://codereview.chromium.org/336253003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@280048 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
provisioning_devices tries to use "adb shell su" to set content
settings. However, "su" is not available for user builds and
thus provisioning_devices fails for devices with user builds.
This CL fixes this failure by only setting the content settings
when the device has a userdebug build.
BUG=385789
Review URL: https://codereview.chromium.org/344233005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@279873 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This adds the --depfile option to a bunch of android's build scripts
(the ones used by gn). It also adds a simple function in build_utils to
calculate the paths of the imported python files.
Currently, the written depfiles just contain that list of python files
(which is much more accurate than the way this is handled in gyp).
BUG=359249
Review URL: https://codereview.chromium.org/341823003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@279546 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The android tests use the python json_results_generator code from Blink
in order to upload results to the flakiness dashboard.
Previously they would import the code from Blink directly, creating a
cross-repo dependency on files that weren't really meant to be public.
In addition, eventually Blink stopped needing the JSONResultsGenerator
classes altogether, so the android scripts were the *only* users.
This patch moves the file over and strips the remaining webkitpy dependencies.
This patch also changes the license block to match the Chromium license.
I traced the commit history of these files; there were only ever two
commits by non-Googlers: one was a trivial variable rename by
rniwa after he had left Google, and the other was a change by zandobersek
which was removed as part of me stripping the webkitpy dependencies, so
I think this is safe.
R=ojan@chromium.org
BUG=242206
Review URL: https://codereview.chromium.org/341143002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@279515 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
1. Static linking (the way it is done today)
2. Standalone dynamic data file bundled with the application
3. Dynamic data file downloaded via the Component Updater
This change does NOT switch any implementation to a different cld data source.
Android/iOS remain pinned to CLD1, and all platforms continue to statically
link the data with cld2_data_source="static".
This change has several important side effects:
1. The gyp variables "cld2_dynamic" and "cld2_is_component" have been removed.
There is now a single variable, "cld2_data_source", that defines which
implementation is to be used.
2. cld_component_installer.[h,cc] and cld_component_installer_unittest.cc are
now conditionally built if and only if cld2_data_source=="component" and
have direct dependencies upon components/translate/content/browser.
3. Almost all preprocesser checks for the CLD data source have been removed,
greatly simplifying code flow. The logic previously gated by these checks
has been split into separate implementation classes whose inclusion is
controlled by the cld2_data_source gyp variable.
For more information, refer to crbug/383769.
BUG=383769
Review URL: https://codereview.chromium.org/333603002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@279415 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When enabling CPU cores for high-perf mode, only warn the
user rather than failing. Only --profiler=perf needs to
fail, since it's results would be invalid (vs. just noisy).
Also, kernel_max returns the number of CPU's supported by
the kernel, but the device may have less cores in practice
(eg. Moto X/Moto E have kernel_max = 4). This uses the cpu*
files to determine the actual number of cores on the device.
BUG=383566
Review URL: https://codereview.chromium.org/336943008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@279321 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
jbudorick@chromium.org
navabi@google.com
bradnelson@google.com
brettw@chromium.org
cjhopman@chromium.org
jochen@chromium.org
mithro@mithis.com
kangil.han@samsung.com
jungjik.lee@samsung.com
anton@chromium.org
rvargas@chromium.org
bashi@chromium.org
rmcilroy@chromium.org
powei@chromium.org
thakis@chromium.org
phoglund@chromium.org
bulach@chromium.org
amogh.bihani@samsung.com
sebastianl@opera.com
zty@chromium.org
tonyg@chromium.org
byoungyoung@google.com
plundblad@chromium.org
andrewhayden@chromium.org
klundberg@chromium.org
spang@chromium.org
glider@chromium.org
qsr@chromium.org
pastarmovj@google.com
rtoy@chromium.org
dpranke@chromium.org
Gordana.Cmiljanovic@imgtec.com
epenner@chromium.org