commit | 615a3a3ace359f2380ff16d6f382cdead3da31de | [log] [tgz] |
---|---|---|
author | Mostyn Bramley-Moore <mostynb@vewd.com> | Mon Aug 20 07:38:01 2018 |
committer | Mostyn Bramley-Moore <mostynb@vewd.com> | Mon Aug 20 07:38:01 2018 |
tree | 0c2d87a5836b2df43d9d34aa06a25035fb3ffcf9 | |
parent | ac9d3edd78849599d1fa5db65992e768ba0568ac [diff] |
if __has_include(X) returns true then X is an input Typically __has_include is used to check if a header is available before #include'ing it. But in some cases __has_include is only used as feature detection, without a subsequent #include (a real world example is in boost's libstdcpp3.hpp). In this case, the goma client won't upload the file that __has_include found, and the remote job will fail this check that succeeded locally. What we should do add X to the list of input files if __has_include(X) evaluates to true, but without processing X for further includes. (And similarly for __has_include_next.) Change-Id: Ibb77ac0691698fc965455973d7f86eb35dc646ca
Goma is a distributed compiler service for open-source project such as Chromium and Android. It's some kind of replacement of distcc+ccache.
NOTE: currently the goma backend is not available for non googlers. We're working so that chromium developers can use it. Stay tuned.
Goma hooks a compile request, and sends it to a backend compile server. If you have plenty of backend servers, a lot of compile can be processed in parallel, for example, -j100, -j500 or -j1000.
Also, the goma backend caches the compile result. If the same compile request comes, the cached result is returned from the goma cache server.
goma client can be built on Linux, Mac, and Win.
On debian or ubuntu,
$ sudo apt-get install libssl-dev libc6-dev-i386
On Mac, install Xcode.
On Windows, install Visual Studio 2017. Community edition is OK.
$ gclient config https://chromium.googlesource.com/infra/goma/client $ gclient sync $ cd client
We assume goma is checked out to $GOMA_SRC
.
$ cd "$GOMA_SRC/client" $ gclient sync $ gn gen --args='is_debug=false' out/Release $ ninja -C out/Release
The build option can be modified with gn args.
is_debug=true/false Do debug build if true. dcheck_always_on=true/false Enable DCHECK always (even in release build). is_asan=true/false Use ASan build (with clang). use_link_time_optimization=true/false Currently working only on Win. If true, /LTCG is enable. use_lld=true/false Use lld for link (it will be fast)
$ cd "$GOMA_SRC/client" $ ./build/run_unittest.py --target=Release --build-dir=out
Goma can be integrated with Chromium/Android development easily.
$ "$GOMA_SRC/client/out/Release/goma_ctl.py" start
In Chromium src, specify the following args in gn args
use_goma = true goma_dir = "$GOMA_SRC/client/out/Release" (Replace $GOMA_SRC to your checkout)
Then build like the following:
$ cd /path/to/chromium/src/out/Release $ ninja -j100 chrome
$ source build/envsetup.sh $ lunch aosp_arm-eng $ GOMA_DIR=$GOMA_SRC/client/out/Release USE_GOMA=true make -j4
Here, -j4
is not related to goma parallelism. Android internally sets -j500
(or -j
with NINJA_REMOTE_NUM_JOBS
environment variable) for goma.
compiler_proxy
$ ./goma_ctl.py ensure_start
gomacc
is prepended to compiler command. For example:$ gomacc clang++ -c foo.cc
make -j100
, ninja -j100
or larger -j. Check http://localhost:8080 to see compiler_proxy is actually working.