mirrored from https://skia.googlesource.com/skia
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
/
.bazelrc
139 lines (116 loc) · 7.35 KB
/
.bazelrc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
# https://bazel.build/concepts/platforms-intro#cxx
# This forces Bazel's C++ rules use platforms to select toolchains instead of the default
# --crosstool_top, --compiler, etc.
build --incompatible_enable_cc_toolchain_resolution
# We do not want Bazel to detect any C++ toolchains on the local machine
# https://github.com/bazelbuild/bazel/blob/4ccc21f2f089971e5f4032397764a4be3549c40a/tools/cpp/cc_configure.bzl#L47
build --action_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
# We would like developers to not upload to the remote build cache, only the RBE workers themselves.
build --remote_upload_local_results=false
# Enforce stricter environment rules, which eliminates some non-hermetic behavior and therefore
# improves both the remote cache hit rate and the correctness and repeatability of the build.
build --incompatible_strict_action_env=true
# This tells Bazel that the host platform can use the hermetic toolchain. This is a small lie until
# Windows support is added.
build --host_platform=//bazel/platform:host_with_hermetic_toolchain
# Linux users (the only platform where we support remote builds currently) can add the following
# line (uncommented) to //bazel/user/buildrc to allow interchangeable operation between local
# operations and remote operations.
# build --host_platform=//bazel/platform:linux_x64_hermetic
# Register our toolchains. We do this here, and not in WORKSPACE.bazel because
# --extra_toolchains has priority over register_toolchains and we conditionally add some toolchains
# for RBE.
build --extra_toolchains=//toolchain:clang_ios_arm64_toolchain
build --extra_toolchains=//toolchain:clang_linux_x64_toolchain
build --extra_toolchains=//toolchain:clang_mac_x64_toolchain
build --extra_toolchains=//toolchain:clang_mac_arm64_toolchain
build --extra_toolchains=//toolchain:clang_host_mac_x64_target_mac_arm64_toolchain
build --extra_toolchains=//toolchain:clang_windows_x64_toolchain
build --extra_toolchains=//toolchain:linux_amd64_ndk_arm64_toolchain
build --extra_toolchains=//toolchain:linux_amd64_ndk_arm32_toolchain
# Hide DEBUG messages from Bazel.
# Many of these are things related to the git checkouts that are not relevent to devs.
# https://bazel.build/reference/command-line-reference#flag--ui_event_filters
build --ui_event_filters=-debug
# For some reason, since upgrading to Go v1.21 and rules_go v0.42.0, Go binaries fail at runtime
# with "fatal error: invalid function symbol table" unless we disable cgo via the below flag.
# Reference:
# https://github.com/bazelbuild/rules_go/blob/d74d9ab34e8789e6a55a2d9caf0e2b3c63202e04/go/modes.rst#build-settings.
build --@io_bazel_rules_go//go/config:pure
# =============================================================================
# Alias to build configurations below. This makes configuring things from
# the command line easier.
# Flags used by Skia tools, not to be used by clients
build --flag_alias=adb_platform=//tools/testrunners/common/android/adb_test_runner:adb_platform
# Public CanvasKit flags
build --flag_alias=ck_enable_fonts=//modules/canvaskit:enable_fonts
build --flag_alias=ck_disable_fonts=no//modules/canvaskit:enable_fonts
build --flag_alias=ck_enable_canvas_polyfill=//modules/canvaskit:enable_canvas_polyfill
build --flag_alias=ck_disable_canvas_polyfill=no//modules/canvaskit:enable_canvas_polyfill
build --flag_alias=ck_enable_embedded_font=//modules/canvaskit:include_embedded_font
build --flag_alias=ck_disable_embedded_font=no//modules/canvaskit:include_embedded_font
build --flag_alias=ck_enable_matrix_js=//modules/canvaskit:include_matrix_js
build --flag_alias=ck_disable_matrix_js=no//modules/canvaskit:include_matrix_js
build --flag_alias=ck_enable_skottie=//modules/canvaskit:enable_skottie
build --flag_alias=ck_disable_skottie=no//modules/canvaskit:enable_skottie
build --flag_alias=ck_enable_skp_serialization=//modules/canvaskit:enable_skp_serialization
build --flag_alias=ck_disable_skp_serialization=no//modules/canvaskit:enable_skp_serialization
build --flag_alias=ck_enable_runtime_effect=//modules/canvaskit:enable_runtime_effect
build --flag_alias=ck_disable_runtime_effect=no//modules/canvaskit:enable_runtime_effect
build --flag_alias=ck_enable_webgl=//modules/canvaskit:enable_webgl
build --flag_alias=ck_exclude_debugger=no//modules/canvaskit:build_for_debugger
build --flag_alias=ck_include_debugger=//modules/canvaskit:build_for_debugger
# =============================================================================
# REMOTE BUILD EXECUTION
# =============================================================================
# =====
# The following was copied from https://github.com/bazelbuild/bazel-toolchains/blob/ea243d43269df23de03a797cff2347e1fc3d02bb/bazelrc/bazel-4.1.0.bazelrc
# We should be free to modify this as we see fit.
#
# Depending on how many machines are in the remote execution instance, setting
# this higher can make builds faster by allowing more jobs to run in parallel.
# Setting it too high can result in jobs that timeout, however, while waiting
# for a remote machine to execute them.
build:remote --jobs=50
# Set several flags related to specifying the platform, toolchain and java
# properties.
build:remote --java_runtime_version=rbe_jdk
build:remote --tool_java_runtime_version=rbe_jdk
# When a remote configuration is chosen, add "remote" to the list of spawn_strategies.
build:remote --spawn_strategy=remote,sandboxed,local
# Enable remote execution so actions are performed on the remote systems.
build:remote --remote_executor=grpcs://remotebuildexecution.googleapis.com
# Some long running tasks are linking because the workers have relatively little RAM
# (at least as of now).
build:remote --remote_timeout=300
# Enable authentication. This will pick up application default credentials by
# default. You can use --google_credentials=some_file.json to use a service
# account credential instead.
# See https://developers.google.com/remote-build-execution/docs/authentication
# To authenticate, you should run gcloud auth application-default login
build:remote --google_default_credentials=true
# End of the copied RBE settings
#=====
# Use the RBE instance on the skia-rbe GCP project.
build:remote --remote_instance_name projects/skia-rbe/instances/default_instance
# The linxu_rbe config will build on RBE and default to compiling for linux_x64 using
# the hermetic toolchain.
build:linux_rbe --config=remote
# On the RBE instances, we also have the Java and C++ toolchain from the Docker image available.
# These need to come after the --extra_toolchains flags (above) that register our hermetic
# toolchains, because we only want these backup toolchains to be used by Bazel internals,
# if at all.
build:linux_rbe --extra_toolchains=//bazel/rbe/gce_linux/java:all
build:linux_rbe --extra_toolchains=//bazel/rbe/gce_linux/config:cc-toolchain
# Make the Linux platform available for selection as an Execution platform (if it is not already,
# e.g. on a Linux host)
build:linux_rbe --extra_execution_platforms=//bazel/platform:linux_x64_hermetic
# Import our specified build configurations
# https://docs.bazel.build/versions/main/best-practices.html#using-the-bazelrc-file
# We chose to split our build configurations into their own file to have better organization
# because we anticipate that file growing large.
import %workspace%/bazel/buildrc
# Device-specific configurations.
import %workspace%/bazel/devicesrc
# Import User's custom builds if they have defined any
try-import %workspace%/bazel/user/buildrc