If use_goma is specified in GYP_DEFINES, gomacc is automatically set as
CC wrapper and CXX wrapper. It uses the default goma directory if the gomadir
option is not given. No need to fix PATH when running ninja (or make).
This is the revival of https://codereview.chromium.org/69293004/.
In https://codereview.chromium.org/69293004/, I removed ANDROID_GOMA_WRAPPER
code, which is actually used. This code supports both way of enabling goma
for Android. You can set GOMA_DIR or you can set -D use_goma=1.
Currently, this works well with ninja (default build system of chromium).
It does not work well with make in some case (e.g. build on linux with make).
Example 1
$ GYP_DEFINES="clang=1 use_goma=1" build/gyp_chromium
(no need to set CC/CXX at this stage)
build.ninja will have
cc = ${HOME}/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang
cxx = ${HOME}/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++
The user can run ninja without setting PATH or so.
$ ninja -C out/Release -j100
Example 2
$ GYP_DEFINES="use_goma=1 gomadir=/path/to/goma" build/gyp_chromium
build.ninja will have
cc = /path/to/goma/gomacc gcc
cxx = /path/to/goma/gomacc g++
user can run ninja without setting PATH or so.
$ ninja -C out/Release -j100
BUG=173686
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=237900
Review URL: https://codereview.chromium.org/96923002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@238630 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Currently, how to build/link the icu data is split between
common.gypi and icu_util.cc
Move it out of icu_util.cc and put it in common.gypi
Also, remove icudata from the dependency list in url.gyp. icuuc depends
on icudata and specifying icuuc alone is sufficient. Otherwise, ninja
complains about multiple rules specified for icudata and a circular
dependency when icu_use_data_file_flag is set to 1 on Linux.
A similar change has to be made in
third_party/WebKit/Source/web/web.gyp.
(see https://codereview.chromium.org/93053003/ )
This CL does not change the actual build process, yet. It's just to prepare
to switch to "icu*.dat" on Mac and Linux.
BUG=72633
TEST=All the configuration/builds go fine on all platforms.
Review URL: https://codereview.chromium.org/89863002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@238567 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
fork chromium. The first patchset below is equivalent to what we have
in KLP branch (minus machine generated makefiles).
This is to unfork the implementation.
Note that the print messages and print_web_view_helper are same (or
very slightly different) from their counterpart in
chrome/renderer/printing and chrome/common/print_messages. The plan is
to start componentizing printing immediately after and remove the
duplicate code
TBR=danakj@chromium.org
BUG=322276
Review URL: https://codereview.chromium.org/54963005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@238196 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Broke the blink android build.
TBR=mkwst@chromium.org
> Add use_goma for GYP_DEFINES
>
> If use_goma is specified in GYP_DEFINES, gomacc is automatically set as
> CC wrapper and CXX wrapper. It uses the default goma directory if the gomadir
> option is not given. No need to fix PATH when running ninja (or make).
> This is the revival of https://codereview.chromium.org/12419003/,
> and expected to work with https://codereview.chromium.org/66303010/.
> Note: Goma team suggest not to put gomadir in PATH if you use use_goma option.
>
> Currently, this works well with ninja (default build system of chromium).
> It does not work well with make in some case (e.g. build on linux with make).
>
> According to the review comment, ANDROID_GOMA_WRAPPER has already been
> obsoleted. ANDROID_GOMA_WRAPPER will be just ignored after this change.
>
> Example 1
> $ GYP_DEFINES="clang=1 use_goma=1" build/gyp_chromium
> (no need to set CC/CXX at this stage)
>
> build.ninja will have
> cc = ${HOME}/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang
> cxx = ${HOME}/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++
>
> The user can run ninja without setting PATH or so.
> $ ninja -C out/Release -j100
>
> Example 2
>
> $ GYP_DEFINES="use_goma=1 gomadir=/path/to/goma" build/gyp_chromium
>
> build.ninja will have
> cc = /path/to/goma/gomacc gcc
> cxx = /path/to/goma/gomacc g++
>
> user can run ninja without setting PATH or so.
> $ ninja -C out/Release -j100
>
> BUG=173686
>
> Review URL: https://codereview.chromium.org/69293004TBR=yyanagisawa@chromium.org
Review URL: https://codereview.chromium.org/96703002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@237911 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
If use_goma is specified in GYP_DEFINES, gomacc is automatically set as
CC wrapper and CXX wrapper. It uses the default goma directory if the gomadir
option is not given. No need to fix PATH when running ninja (or make).
This is the revival of https://codereview.chromium.org/12419003/,
and expected to work with https://codereview.chromium.org/66303010/.
Note: Goma team suggest not to put gomadir in PATH if you use use_goma option.
Currently, this works well with ninja (default build system of chromium).
It does not work well with make in some case (e.g. build on linux with make).
According to the review comment, ANDROID_GOMA_WRAPPER has already been
obsoleted. ANDROID_GOMA_WRAPPER will be just ignored after this change.
Example 1
$ GYP_DEFINES="clang=1 use_goma=1" build/gyp_chromium
(no need to set CC/CXX at this stage)
build.ninja will have
cc = ${HOME}/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang
cxx = ${HOME}/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++
The user can run ninja without setting PATH or so.
$ ninja -C out/Release -j100
Example 2
$ GYP_DEFINES="use_goma=1 gomadir=/path/to/goma" build/gyp_chromium
build.ninja will have
cc = /path/to/goma/gomacc gcc
cxx = /path/to/goma/gomacc g++
user can run ninja without setting PATH or so.
$ ninja -C out/Release -j100
BUG=173686
Review URL: https://codereview.chromium.org/69293004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@237900 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Fuzzer child process takes messages from a testcase file specified by --ipc-fuzzer-testcase and sends them across IPC.
Renderer process is replaced by the fuzzer process using --renderer-cmd-prefix, which is only supported under POSIX.
BUG=260848
Review URL: https://codereview.chromium.org/18254010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@237795 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The previous expansion using <(PRODUCT_DIR)/../.. did not work correctly
if one was using a different build directory layout (out-of-source
builds, or some build directory with a different number of
subdirectories).
Solve this by doing the same as the sysroot variables: stop using
relative paths from the build directory and extract absolute paths using
DEPTH.
TEST=./build/gyp_chromium -Goutput_dir=/somewhere/else
R=phajdan.jr@chromium.org,thakis@chromium.org,dpranke@chromium.org
Review URL: https://codereview.chromium.org/83673002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@236822 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is useful for embedded linux setups, which often don't include udev support.
TEST=Build content_shell on linux with use_udev=0 then run ldd on output binaries to verify libudev is not listed (and is listed if built with use_udev=1 or unspecified)
BUG=318315,318413
Review URL: https://codereview.chromium.org/12374068
git-svn-id: http://src.chromium.org/svn/trunk/src/build@236204 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This makes base build on Linux when use_glib is set to 0. The only glib
bits we are currently using in that configuration are g_get_home_dir()
and g_try_malloc().
Use of g_get_home_dir() is not essential. Without glib, we can just rely
on the $HOME environment variable always.
Use of g_try_malloc() is just a way to cause a large memory allocation
from a shared library. We can achieve the same effect using asprintf().
BUG=318315, 318413, 170408
Review URL: https://codereview.chromium.org/69953025
git-svn-id: http://src.chromium.org/svn/trunk/src/build@236162 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This adds a use_cairo gyp variable that removes cairo from the build.
To build skia without cairo, we need the code in
bitmap_platform_device_android.cc.
To make all platforms build the correct files, rename
bitmap_platform_device_linux to bitmap_platform_device_cairo and
rename bitmap_platform_device_android to bitmap_platform_device_skia.
We'll use bitmap_platform_device_skia for Android and for embedded
content shell.
BUG=318315, 318413
Review URL: https://codereview.chromium.org/59133008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@236037 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The linux wifi data provider adds an external dependency on libdbus.
This prevents building content_browser on linux systems that don't
include it (particularly embedded ones such as chromecast).
Introduce use_dbus gyp variable and remove this dependency when
use_dbus==0.
BUG=318315,318413
Review URL: https://codereview.chromium.org/59323007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@234894 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In VS2013, remoting_host_event_logger.lib fails with:
FAILED: E:\b\depot_tools\python_bin\python.exe gyp-win-tool link-wrapper environment.x86 lib.exe /nologo /ignore:4221 /OUT:obj\remoting\remoting_host_event_logger.lib @obj\remoting\remoting_host_event_logger.lib.rsp
LINK : warning LNK4068: /MACHINE not specified; defaulting to X64
obj\remoting\host\remoting_host_event_logger.host_event_logger_win.obj : fatalerror LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
This is because if unspecified, lib.exe chooses the target architecture
based on the first input file. In this lib, the first file (there's only
2) happens to be a .res compiled from a .rc, which doesn't have an
architecture. Because we use the amd64 toolchain, lib decides to guess
that it should use x64. This fails to lib because the other .cc input is
x86.
After adding support for setting the architecture for libs in gyp here
https://codereview.chromium.org/68133006/ this sets it explicitly on our
libs too.
R=cpu@chromium.org
BUG=309197
Review URL: https://codereview.chromium.org/61893020
git-svn-id: http://src.chromium.org/svn/trunk/src/build@234656 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Seems to cause two Chrome Memory bots to fail consistently with the error
"Failed cbuildbot failed buildpackages failed report"
See these links:
http://build.chromium.org/p/chromium.memory/builders/Chromium%20OS%20(x86)%20ASANhttp://build.chromium.org/p/chromium.memory/builders/Chromium%20OS%20(amd64)%20ASAN
If those links break, mpearson@ has a copy of the failure output
(too long to paste here).
> Set the default ASan options for executables built with ASan on Linux.
>
> This CL introduces a module, base/debug/sanitizer_options.cc, which will override
> the defaults for various dynamic tools (only ASan at this moment). For every executable
> built with a dynamic tool this module will be linked into that executable, providing
> weak functions to be called by the tool.
>
> The existing declaration of __asan_default_options() in chrome/app/chrome_exe_main_gtk.cc
> has been moved into sanitizer_options.cc (now every binary built with GOOGLE_CHROME_BUILD=1
> will have the same options as google-chrome-asan.
> The existing declaration of __asan_default_options() in chrome/nacl/nacl_helper_linux.cc
> has been kept as is, but we had to remove -Wl,-u_sanitizer_options_link_helper to avoid picking sanitizer_options.cc.
>
> GYP changes for OSX and iOS will be committed separately.
>
> BUG=302040
> R=thakis@chromium.org
>
> Review URL: https://codereview.chromium.org/25687005TBR=glider@chromium.org
Review URL: https://codereview.chromium.org/68843003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@234232 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
mostynb@opera.com
yyanagisawa@chromium.org
jshin@chromium.org
wfh@chromium.org
thakis@chromium.org
alextaran@chromium.org
sgurun@chromium.org
jochen@chromium.org
hashimoto@chromium.org
eae@chromium.org
aedla@chromium.org
scottmg@chromium.org
spang@chromium.org
raphael.kubo.da.costa@intel.com
sugoi@chromium.org
phajdan.jr@chromium.org
agable@chromium.org
bauerb@chromium.org
justincohen@chromium.org
mpearson@chromium.org