skia2/bazel/buildrc
Kevin Lubick c123b5a93d [bazel] Add rules for CanvasKit and dependent modules
This may look like a lot, but //modules/canvaskit/BUILD.bazel
is nearly identical to how it was with gazelle:
162dfca340/modules/canvaskit/BUILD.bazel

I removed the "wasm_gm_tests" targets from it, because they
had bitrotted slightly and fixing them is its own task.

CanvasKit depends on Skottie and Particles, which depend on
the SkParagraph, SkShaper, SkUnicode, and SkResources modules.

I've structured the BUILD.bazel files in the //modules directory
in a similar fashion as the "hierarchical filegroup"
introduced in https://skia-review.googlesource.com/c/skia/+/543977

Suggested Review Order
 - //modules/skottie/...
 - //modules/skparagraph/...
 - all other modules.
 - Note that modules/canvaskit/go/gold_test_env/BUILD.bazel is
   generated from gazelle, because we like how gazelle handles
   golang files and deps.
 - All other files in any order.

Change-Id: I0aa9e6f81dba2c00f15cae7b19fe49a2027dcf1d
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544676
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-05-31 14:14:54 +00:00

40 lines
2.6 KiB
Plaintext

# This file contains the build configurations of Skia that we use for testing on the CI.
# These allow a short-form reference for our supported combinations of build features.
# https://bazel.build/docs/bazelrc#config
#
# For most build configurations, we will want to set the --cc_output_directory_tag [1]
# with a unique identifier per configuration name.
#
# By default, Bazel's "unique target BuildConfiguration" [2] incorporates the compilation_mode,
# the target platform, and some suffixes to avoid Bazel-caused and user-caused conflicts. [3] [4]
# For example, a default output directory might look like "k8-fastbuild-ST-6a54c1377847".
# Inside this output directory is a subfolder for the target (e.g. executable) name.
#
# Notably, the flags that we turn on and off via //bazel/common_config_settings do not affect
# the output directory. The output directory is used to store compiled object files (.o files)
# and generated dependency files (e.g. the output of clang --write-dependencies [5]), so having
# these be overwritten unnecessarily will slow down incremental rebuilds when switching between
# building different configurations of the same targets.
#
# [1] https://bazel.build/reference/command-line-reference#flag--cc_output_directory_tag
# [2] https://bazel.build/docs/output_directories#layout-diagram
# [3] https://github.com/bazelbuild/bazel/blob/ad37a3748c78e0ee903b56366322c70ab8b22187/CODEBASE.md#the-structure-of-the-output-directory
# [4] https://github.com/bazelbuild/bazel/blob/e0e589658463beb9605030b4820dcc97e6a36f48/src/main/java/com/google/devtools/build/lib/analysis/config/OutputDirectories.java#L198-L236
# [5] https://clang.llvm.org/docs/ClangCommandLineReference.html#dependency-file-generation
# These are examples of the syntax to create build configurations. As of May 2022, our
# Bazel configurations are still being made.
build:release --compilation_mode=opt
build:debug --compilation_mode=dbg
# We use spawn_strategy=local for CanvasKit builds because emscripten assumes there
# is a cache in the home directory that it needs to fill with compiled versions of libc etc.
# https://emscripten.org/docs/tools_reference/emcc.html
# By setting spawn_strategy=local, we can avoid recompiling all of this for every compilation
# unit, by letting the cache be used (and not dropped from the sandbox), which gets expensive.
# Local testing showed using the local strategy sped up a clean build from 9.5 minutes
# to 1 minute. https://bazel.build/docs/user-manual#execution-strategy
build:ck_release --config=release --spawn_strategy=local
build:ck_debug --config=debug --spawn_strategy=local