fed97e8f40
A new RBE worker-pool called gce_linux was created in conjunction with this CL. See https://docs.google.com/document/d/14xMZCKews69SSTfULhE8HDUzT5XvPwZ4CvRufEvcZ74/edit# for some details on that. Note: everything under bazel/rbe/gce_linux was autogenerated and can be ignored from manual review. It basically specifies what files are on the RBE image that are necessary for running Bazel. Testing it out can be done by authenticating for RBE gcloud auth application-default login --no-browser Then, run make -C bazel rbe_known_good_builds to test it out. On my 4 core laptop with an empty local cache, but a warm remote cache, the build took <2 min instead of the 10+ minutes it would have [1]. The folder structure in //bazel/rbe is meant to let us have multiple remote configurations there, e.g. //bazel/rbe/gce_windows. Suggested Review Order: - bazel/rbe/README.md - bazel/rbe/gce_linux_container/Dockerfile to see the bare-bones RBE image. - bazel/rbe/BUILD.bazel to see a custom platform defined. It is nearly identical to the autogenerated one in bazel/rbe/gce_linux/config/BUILD, with one extra field to force the gce_linux pool to be used. - .bazelrc to see the settings needed to make --config=linux-rbe work. The naming convention was inspired by SkCMS's setup [2], and allows us to have some common RBE settings (i.e. config:remote) and some specialized ones for the given host machine (e.g. config:linux-rbe) A very important, but subtle configuration, is on line 86 of .bazelrc where we say to use our hermetic toolchain and not whatever C++ compiler and headers are on the host machine (aka the RBE container). - toolchain/build_toolchain.bzl to see some additional dependencies needed in the toolchain (to run IWYU) which I had installed locally but didn't realize were important. - third_party/BUILD.bazel to see an example of how failing to specify all files can result in something that works locally, but fails remotely. --execution_log_json_file=/tmp/execlog.json helped debug these issues. - All other files. [1] http://go/scrcast/NjM1ODE4MDI0NzM3MTc3Nnw3ODViZmFkMi1iOA [2] https://skia.googlesource.com/skcms/+/30c8e303800c256febb03a09fdcda7f75d119b1b/.bazelrc#20 Change-Id: Ia0a9e6a06c1a13071949ab402dc5d897df6b12e1 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524359 Reviewed-by: Leandro Lovisolo <lovisolo@google.com> |
||
---|---|---|
.. | ||
angle2 | ||
brotli | ||
cpu-features | ||
d3d12allocator | ||
dng_sdk | ||
etc1 | ||
expat | ||
freetype2 | ||
harfbuzz | ||
highway | ||
icu | ||
imgui | ||
libjpeg-turbo | ||
libjxl | ||
libmicrohttpd | ||
libpng | ||
libwebp | ||
lua | ||
native_app_glue | ||
oboe | ||
piex | ||
sfntly | ||
skcms | ||
spirv-cross | ||
vulkanmemoryallocator | ||
wuffs | ||
zlib | ||
BUILD.bazel | ||
BUILD.gn | ||
file_map_for_bazel.json | ||
README | ||
third_party.gni |
The third_party directory contains a set of dependencies from outside sources that are needed to build various components and tools within Skia. Some of these dependencies reside within the Skia repo, while others are pulled from other repositories and placed in the third_party/externals directory during build. These external dependencies are defined in a DEPS file. Products in third_party are subject to their own respective license terms. The license for each project should be included in the source itself via a license header or file. If the source itself does not include a license header or file, create a README that refers to reliable documentation of the project's license terms on the web.