bazel/platform/BUILD.bazel

# https://github.com/bazelbuild/bazel-toolchains/blob/master/rules/exec_properties/exec_properties.bzl
load("@bazel_toolchains//rules/exec_properties:exec_properties.bzl", "create_rbe_exec_properties_dict")

# https://bazel.build/concepts/platforms-intro
# https://bazel.build/docs/platforms
platform(
    name = "linux_x64_hermetic",
    constraint_values = [
        "@platforms//os:linux",  # https://github.com/bazelbuild/platforms/blob/main/os/BUILD
        "@platforms//cpu:x86_64",  # https://github.com/bazelbuild/platforms/blob/main/cpu/BUILD
        ":cgo_off",  # Necessary to build on RBE.
        ":use_hermetic_toolchain",
    ],
    # We specify exec_properties because we have an RBE instance that matches this platform.
    # exec_properties specify some information that is passed along the Remote Execution API
    # (REAPI) to the dispatcher which will use it to direct the request to the appropriate
    # machine/worker, using the Remote Worker API (RWAPI).
    # http://go/skolo-rbe
    # These properties will be ignored when running locally, but we must specify them if we want
    # the action cache to treat things built on a local Linux machine to be the same as built on
    # a Linux RBE worker (which they should, assuming our hermetic toolchain *is* hermetic).
    # See https://github.com/bazelbuild/bazel/blob/f28209df2b0ebeff1de0b8b7f6b9e215d890e753/src/main/java/com/google/devtools/build/lib/actions/ActionKeyCacher.java#L67-L73
    # for how the exec_properties and execution platform impact the action cache.
    exec_properties = create_rbe_exec_properties_dict(
        container_image = "docker://gcr.io/skia-public/rbe_linux@sha256:82e8a4c7d06c8f47bbc08ee899c4c03069af0f7f4d8c0d958a50a23d814405e6",
        os_family = "Linux",
        pool = "gce_linux",
    ),
)

platform(
    name = "mac_x64_hermetic",
    constraint_values = [
        "@platforms//os:macos",
        "@platforms//cpu:x86_64",
        ":cgo_off",
        ":use_hermetic_toolchain",
    ],
)

platform(
    name = "mac_arm64_hermetic",
    constraint_values = [
        "@platforms//os:macos",
        "@platforms//cpu:arm64",
        ":cgo_off",
        ":use_hermetic_toolchain",
    ],
)

platform(
    name = "windows_x64_hermetic",
    constraint_values = [
        "@platforms//os:windows",
        "@platforms//cpu:x86_64",
        ":cgo_off",
        ":use_hermetic_toolchain",
    ],
)

platform(
    name = "host_with_hermetic_toolchain",
    constraint_values = [
        ":cgo_off",  # Necessary to build locally (i.e. non-RBE builds).
        ":use_hermetic_toolchain",
    ],
    parents = ["@local_config_platform//:host"],
)

platform(
    name = "android_arm32",
    constraint_values = [
        "@platforms//os:android",
        "@platforms//cpu:armv7",
    ],
)

platform(
    name = "android_arm64",
    constraint_values = [
        "@platforms//os:android",
        "@platforms//cpu:arm64",
    ],
)

# This platform covers only the ios hardware which is arm64.
# Simulator support if any will be a separate platform.
platform(
    name = "ios",
    constraint_values = [
        "@platforms//os:ios",
        "@platforms//cpu:arm64",
    ],
)

# This constraint allows us to force Bazel to resolve our hermetic toolchain to build
# the target and not a default one (e.g. on the Linux RBE instance). We do this by
# adding the constraint to our platforms that describe the target we want Bazel to build for.
# https://bazel.build/reference/be/platform#constraint_setting
constraint_setting(name = "skia_hermetic_toolchain")

constraint_value(
    name = "use_hermetic_toolchain",
    constraint_setting = ":skia_hermetic_toolchain",
    visibility = ["//visibility:public"],
)

# When added to a Bazel platform, this constraint has the effect of disabling cgo, meaning that
# the C++ compiler will never be invoked when building Go binaries.
#
# For context, when cgo is enabled, the C++ compiler will be involved when building Go binaries,
# even for pure builds (e.g. "bazel build //some:target --@io_bazel_rules_go//go/config:pure").
# Presumably this is because some parts of the Go stdlib are written in C. It is unclear to
# lovisolo@ whether disabling cgo means some parts of the Go stdlib become unavailable.
#
# We want to disable cgo because, for some unknown reason, the directory structure under which
# clang_trampoline_linux.sh is executed is slightly different when building Go-related C/C++ code.
# We previously worked around this issue by adding a special case to clang_trampoline_linux.sh
# where clang is invoked using a different path (see
# https://skia-review.googlesource.com/c/skia/+/791499/11/toolchain/linux_trampolines/clang_trampoline_linux.sh).
# Unfortunately this does not work under macOS because clang is not found anywhere in the directory
# tree under which clang_trampoline_mac.sh is invoked. By disabling cgo, we get rid of this problem
# altogether. Fortunately all our Go code still compiles without cgo.
#
# It is unclear whether this is a rules_go bug, or if there's something specific about our hermetic
# C++ toolchains (Linux and macOS) that is causing the build to fail when cgo is enabled.
#
# Note that the @io_bazel_rules_go//go/toolchain:cgo_off constraint is not well documented.
# lovisolo@ discovered this constraint because it was mentioned on some issues and PRs in the
# rules_go repository and some other places, namely:
#
#  - https://github.com/bazelbuild/rules_go/issues/2115#issuecomment-507467744
#  - https://github.com/bazelbuild/rules_go/issues/2591#issuecomment-670527288
#  - https://github.com/aspect-build/bazel-lib/pull/289/files#diff-963e4331fa8afa39ffa09be04587bc2a66f8cbab3416842e1554a6825ee532ecR27
#
# Note also that there is an ongoing effort to make C++ toolchains optional in rules_go:
# https://github.com/bazelbuild/rules_go/pull/3390.
alias(
    name = "cgo_off",
    actual = "@io_bazel_rules_go//go/toolchain:cgo_off",
)