1# https://github.com/bazelbuild/bazel-toolchains/blob/master/rules/exec_properties/exec_properties.bzl 2load("@bazel_toolchains//rules/exec_properties:exec_properties.bzl", "create_rbe_exec_properties_dict") 3 4# https://bazel.build/concepts/platforms-intro 5# https://bazel.build/docs/platforms 6platform( 7 name = "linux_x64_hermetic", 8 constraint_values = [ 9 "@platforms//os:linux", # https://github.com/bazelbuild/platforms/blob/main/os/BUILD 10 "@platforms//cpu:x86_64", # https://github.com/bazelbuild/platforms/blob/main/cpu/BUILD 11 ":cgo_off", # Necessary to build on RBE. 12 ":use_hermetic_toolchain", 13 ], 14 # We specify exec_properties because we have an RBE instance that matches this platform. 15 # exec_properties specify some information that is passed along the Remote Execution API 16 # (REAPI) to the dispatcher which will use it to direct the request to the appropriate 17 # machine/worker, using the Remote Worker API (RWAPI). 18 # http://go/skolo-rbe 19 # These properties will be ignored when running locally, but we must specify them if we want 20 # the action cache to treat things built on a local Linux machine to be the same as built on 21 # a Linux RBE worker (which they should, assuming our hermetic toolchain *is* hermetic). 22 # See https://github.com/bazelbuild/bazel/blob/f28209df2b0ebeff1de0b8b7f6b9e215d890e753/src/main/java/com/google/devtools/build/lib/actions/ActionKeyCacher.java#L67-L73 23 # for how the exec_properties and execution platform impact the action cache. 24 exec_properties = create_rbe_exec_properties_dict( 25 container_image = "docker://gcr.io/skia-public/rbe_linux@sha256:82e8a4c7d06c8f47bbc08ee899c4c03069af0f7f4d8c0d958a50a23d814405e6", 26 os_family = "Linux", 27 pool = "gce_linux", 28 ), 29) 30 31platform( 32 name = "mac_x64_hermetic", 33 constraint_values = [ 34 "@platforms//os:macos", 35 "@platforms//cpu:x86_64", 36 ":cgo_off", 37 ":use_hermetic_toolchain", 38 ], 39) 40 41platform( 42 name = "mac_arm64_hermetic", 43 constraint_values = [ 44 "@platforms//os:macos", 45 "@platforms//cpu:arm64", 46 ":cgo_off", 47 ":use_hermetic_toolchain", 48 ], 49) 50 51platform( 52 name = "host_with_hermetic_toolchain", 53 constraint_values = [ 54 ":cgo_off", # Necessary to build locally (i.e. non-RBE builds). 55 ":use_hermetic_toolchain", 56 ], 57 parents = ["@local_config_platform//:host"], 58) 59 60platform( 61 name = "android_arm32", 62 constraint_values = [ 63 "@platforms//os:android", 64 "@platforms//cpu:armv7", 65 ], 66) 67 68platform( 69 name = "android_arm64", 70 constraint_values = [ 71 "@platforms//os:android", 72 "@platforms//cpu:arm64", 73 ], 74) 75 76# This constraint allows us to force Bazel to resolve our hermetic toolchain to build 77# the target and not a default one (e.g. on the Linux RBE instance). We do this by 78# adding the constraint to our platforms that describe the target we want Bazel to build for. 79# https://bazel.build/reference/be/platform#constraint_setting 80constraint_setting(name = "skia_hermetic_toolchain") 81 82constraint_value( 83 name = "use_hermetic_toolchain", 84 constraint_setting = ":skia_hermetic_toolchain", 85 visibility = ["//visibility:public"], 86) 87 88# This constraint allows us to have clang use a "trivial_abi" that saves code size but 89# breaks clients that aren't expecting it. 90# http://review.skia.org/633089 91# https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/ 92constraint_setting(name = "clang_abi_mode") 93 94constraint_value( 95 name = "trivial_abi", 96 constraint_setting = ":clang_abi_mode", 97 visibility = ["//visibility:public"], 98) 99 100# When added to a Bazel platform, this constraint has the effect of disabling cgo, meaning that 101# the C++ compiler will never be invoked when building Go binaries. 102# 103# For context, when cgo is enabled, the C++ compiler will be involved when building Go binaries, 104# even for pure builds (e.g. "bazel build //some:target --@io_bazel_rules_go//go/config:pure"). 105# Presumably this is because some parts of the Go stdlib are written in C. It is unclear to 106# lovisolo@ whether disabling cgo means some parts of the Go stdlib become unavailable. 107# 108# We want to disable cgo because, for some unknown reason, the directory structure under which 109# clang_trampoline_linux.sh is executed is slightly different when building Go-related C/C++ code. 110# We previously worked around this issue by adding a special case to clang_trampoline_linux.sh 111# where clang is invoked using a different path (see 112# https://skia-review.googlesource.com/c/skia/+/791499/11/toolchain/linux_trampolines/clang_trampoline_linux.sh). 113# Unfortunately this does not work under macOS because clang is not found anywhere in the directory 114# tree under which clang_trampoline_mac.sh is invoked. By disabling cgo, we get rid of this problem 115# altogether. Fortunately all our Go code still compiles without cgo. 116# 117# It is unclear whether this is a rules_go bug, or if there's something specific about our hermetic 118# C++ toolchains (Linux and macOS) that is causing the build to fail when cgo is enabled. 119# 120# Note that the @io_bazel_rules_go//go/toolchain:cgo_off constraint is not well documented. 121# lovisolo@ discovered this constraint because it was mentioned on some issues and PRs in the 122# rules_go repository and some other places, namely: 123# 124# - https://github.com/bazelbuild/rules_go/issues/2115#issuecomment-507467744 125# - https://github.com/bazelbuild/rules_go/issues/2591#issuecomment-670527288 126# - https://github.com/aspect-build/bazel-lib/pull/289/files#diff-963e4331fa8afa39ffa09be04587bc2a66f8cbab3416842e1554a6825ee532ecR27 127# 128# Note also that there is an ongoing effort to make C++ toolchains optional in rules_go: 129# https://github.com/bazelbuild/rules_go/pull/3390. 130alias( 131 name = "cgo_off", 132 actual = "@io_bazel_rules_go//go/toolchain:cgo_off", 133) 134