AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
cdf338247b
skia2/WORKSPACE.bazel

297 lines
10 KiB
Plaintext
Raw Normal View History

[infra] Add hermetic toolchain for C/C++ using Clang+Musl This can successfully build a C library: bazel build --config=clang //third_party:libpng This can build and run a statically-linked executable: bazel test --config=clang //:bazel_test For more verbose compile and linking output, add the `--features diagnostic` flag to a Bazel command (see _make_diagnostic_flags() in toolchain/clang_toolchain_config.bzl. Similarly, a `--features print_search_dirs` can be used to show where clang is looking for libraries etc to link against. These features are made available for easier debugging. Suggested review order: - Read https://docs.bazel.build/versions/4.2.1/tutorial/cc-toolchain-config.html if unfamiliar with setting up C++ toolchains in Bazel - .bazelrc and WORKSPACE.bazel that configure use and download of the toolchain (Clang 13, musl 1.2.2) - toolchain/build_toolchain.bzl which downloads and assembles the toolchain (w/o installing anything on the host machine) - toolchain/BUILD.bazel and toolchain/*trampoline.sh to see the setup of the toolchain rules. - toolchain/clang_toolchain_config.bzl to see the configuration of the toolchain. Pay special attention to the various command line flags that are set. - See that tools/bazel_test.cc has made a new home in experimental/bazel_test/bazel_test.cpp, with a companion BUILD.bazel. Note the addition of some function calls that test use of the C++ standard library. The number being used to test the PNG library is the latest and greatest that verifies we are compiling the one brought in via DEPS (and not a local one). - third_party/* to see how png (and its dependent zlib) have been built. Pay special attention to the musl_compat hack to fix static linking (any idea what the real cause is?) - //BUILD.bazel to see definition of the bazel_test executable. Change-Id: I7b0922d0d45cb9be8df2fd5fa5a1f48492654d5f Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/461178 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2021-10-20 20:20:42 +00:00
workspace(name = "skia")
bazel baby steps A few first steps toward a Bazel build. To try it out, I think just $ bazel test ... I added third_party to .bazelignore to prevent Bazel from looking there. It can handle external dependencies itself, so no need to poke into what we sync from DEPS. Some of those have Bazel configs and we don't want to be building them yet. I've started by with libpng using new_git_repository(), mostly because it's small, with a mildly complex build, and needs dependencies of its own, zlib. Mysteriously zlib is built-in to Bazel, so that was easy. Next up is probably a dependency that does support Bazel, using git_repository(). That should make sure we can handle the full mix. Change-Id: I5775a1b254d341b9a90630aa1cc433a24167f2fd Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316636 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2020-09-11 16:11:33 +00:00
[bazel] Sketch out changes for Mac toolchain Change-Id: Idae84d8d9538012e5cfb75a1a477dbc72a4da5bc Bug: skia:13125 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/526264 Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
2022-04-01 12:29:11 +00:00
load("//toolchain:download_toolchains.bzl", "download_toolchains_for_skia")
[bazel] Add support for Macs to make Linux RBE builds The big change here is having the C++ toolchain use Bazel platforms instead of the C++ specific flags/setup. In Bazel, platforms are a general purpose way to define things like os, cpu architecture, etc. We were not using platforms previously, because the best documentation at the time focused on the old ways. However, the old ways were clumsy/difficult when trying to manage cross-compilation, specifically when trying to have a Mac host trigger a build on our Linux RBE system targeting a Linux x64 system. Thus, rather than keep investing in the legacy system, this CL migrates us to using platforms where possible. Suggested background reading to better understand this CL: - https://bazel.build/concepts/platforms-intro - https://bazel.build/docs/platforms - https://bazel.build/docs/toolchains#registering-building-toolchains The hermetic toolchain itself is not changing in this CL (and likely does not need to), only how we tell Bazel about it (i.e. registering it) and how Bazel decides to use it (i.e. resolving toolchains). Here is my understanding of how platforms and toolchains interact (supported by some evidence from [1][2]) - Bazel needs to resolve platforms for the Host, Execution, and Target. - If not specified via flags, these are the machine from which Bazel is invoked, aka "@local_config_platform//:host". - With this CL, the Host could be a Mac laptop, the Execution platform is our Linux RBE pool, and the Target is "a Linux system with a x64 CPU" - To specify the Host, that is, describe to Bazel the capabilities of the system it is running on, one can set --host_platform [3] with a label pointing to a platform() containing the appropriate settings. Tip: have this platform inherit from @local_config_platform//:host so it can add to any of the constraint_settings and constraint_values that Bazel deduces automatically. - To specify the Target platform(s), that is, the system on which a final output resides and can execute, one can set the --platforms flag with a label referencing a platform(). - Bazel will then choose an execution platform to fulfill that request. Bazel will look through a list of available platforms, which can be augmented* with the --extra_execution_platforms. Platforms specified by this flag will be considered higher than the default platforms! - Having selected the appropriate platforms, Bazel now needs to select a toolchain to actually run the actions of the appropriate type. - Bazel looks through the list of available toolchains and finds one that "matches" the Execution and the Target platform. This means, the toolchain's exec_compatible_with is a strict subset of the Execution platform and the toolchain's target_compatible_with is a strict subset of the Target platform. To register toolchains* (i.e. add them to the resolution list), we use --extra_toolchains. Once Bazel finds a match, it stops looking. Using --toolchain_resolution_debug=".*" makes Bazel log how it is resolving these toolchains and what execution platform it picked. * We can also register execution platforms and toolchains in WORKSPACE.bazel [4], but the flags come with higher priority and that made resolution a bit tricky. Also, when we want to conditionally add them (e.g. --config=linux_rbe), we cannot remove them conditionally in the WORKSPACE.bazel file. The above resolution flow directly necessitated the changes in this CL. Example usage of the new configs and platforms: # Can be run on a x64 Linux host and uses the hermetic toolchain. bazel build //:skia_public # Can be run on Mac or Linux and uses the Linux RBE system along # with the hermetic toolchain to compile a binary for Linux x64. bazel build //:skia_public --config=linux_rbe --config=for_linux_x64 # Shorthand for above bazel build //:skia_public --config=for_linux_x64_with_rbe Notice we don't have to type out --config=clang_linux anymore! That was due to me reading the Bazel docs more carefully and realizing we can set options for *all* Bazel build commands. Current Limitations: - Targets which require a py_binary (e.g. Dawn's genrules) will not work on RBE when cross compiling because the python runtime we download is for the host machine, not the executor. This means //example:hello_world_dawn does not work on Mac when cross-compiling via linux_rbe. - Mac M1 linking not quite working with SkOpts settings. Probably need to set -target [5] Suggested Review order: - toolchain/BUILD.bazel Notice how we do away with cc_toolchain_suite for toolchain. These have the same role: giving Bazel the information about where a toolchain can run. The platforms one is more expressive (IMO), allowing us to say both where to run the toolchain and what it can make. In order to more easily force the use of our hermetic toolchain, but also allow the hermetic toolchain to be used on RBE, we specify "use_hermetic_toolchain" only on the target, because the RBE image does not have the hermetic toolchain on it by default (but can certainly run it). - bazel/platform/BUILD.bazel to see the custom constraint_setting and corresponding constraint_value. The names for both of these are completely arbitrary - they do not need to have any deeper meaning or relation to any file or Docker image or system or any other constraints. Think of the constraint_setting as an Enum and the constraint_value being the one and only member. We need to pass around a constant value, not a type, so we need to provide the constraint_value (e.g. in toolchain/BUILD.bazel) but not a constraint_setting. However we need a constraint_setting declared so we can make a constraint_value of that "type". Notice the platform declared here - it allows us to force Bazel to use the hermetic toolchain because of the extra constraint_value. - .bazelrc I set a few flags that will be on for all bazel build commands. Importantly, this causes the C++ build logic to use platforms and not the old, bespoke way. I also found a way to avoid using the local toolchain on the host, which will hopefully lead to clearer errors if platforms are mis-specified instead of odd compile errors because the host toolchain is too old or something. There are also a few RBE settings tweaked to be a bit more modern, as well the new shorthands for specifying target platforms (e.g. for_linux_x64). - bazel/buildrc where we have to turn off the platforms logic for emscripten https://github.com/emscripten-core/emsdk/issues/984 - bazel/rbe/BUILD.bazel for a fix in the platform description that makes it work on Mac. - Notice that _m1 has been removed from the mac-related toolchain files because the same toolchain should work on both architectures. - All other changes in any order. [1] https://bazel.build/docs/toolchains#debugging-toolchains [2] https://bazel.build/docs/toolchains#toolchain-resolution [3] https://bazel.build/reference/command-line-reference [4] https://bazel.build/docs/toolchains#registering-building-toolchains [5] https://github.com/google/skia/blob/17dc3f16fc78477503ba1ef484c3b47bc3aab893/gn/skia/BUILD.gn#L258-L271 Change-Id: I515c114099d659639a808f74e47d489a68b7af62 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549737 Reviewed-by: Erik Rose <erikrose@google.com> Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
2022-06-22 19:28:10 +00:00
download_toolchains_for_skia("clang_linux_amd64", "clang_mac")
[bazel] Sketch out changes for Mac toolchain Change-Id: Idae84d8d9538012e5cfb75a1a477dbc72a4da5bc Bug: skia:13125 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/526264 Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
2022-04-01 12:29:11 +00:00
[infra] Add initial Bazel rules and files These rules can be used to build our GMs on WASM+WebGL and libskia.a with just the CPU backend (and most other features turned off). This can be done with the following commands: - bazel build //modules/canvaskit:gm-bindings-wasm --gpu_backend=gl_backend --with_gl_standard=webgl_standard - bazel build :skia-core --config clang This pivots slightly from http://review.skia.org/463517 by using config_settings [1] instead of platforms for the optional features that we control. This pivot was suggested in [2] We have BUILD.bazel files in many of the subdirectories that specify filegroups for the appropriate files. In an effort to make //BUILD.bazel more readable, it is the responsibility of these subfolders to deal with conditionally including certain .h or .cpp files. This is done using select statements and config_settings or platform constraints as necessary. For example, src/gpu/BUILD.bazel will different private filegroups for each of the supported gpu backends [3] and a more-visible filegroup called "srcs" that has the right selection of the private files to be used for compilation. An effort has been made to avoid using glob() in our BUILD.bazel files. These file lists were made by using `ls -1` and some regex to add in quotes. We might want to make a helper script to assist with that, if necessary. To specify which options we have, the settings in //bazel/common_config_settings/BUILD.bazel have been redesigned. They make use of a macro `string_flag_with_values` that removes the boilerplate. Patchset 36 shows what the file looks like w/o the macro. The top level BUILD.bazel file will still need to use some logic to handle defines, because local_defines is a list of strings, not a list of labels [4]. Suggested Review Order: - WORKSPACE.bazel to see the new dependencies on the emsdk toolchain and bazel_skylib - bazel/common_config_settings/* to see the few settings defined (we have more to define, see BUILD.gn and //gn/skia.gni for ideas) - BUILD.bazel to see the "skia-core" cc_library rule. See also "gms" and "tests" - modules/canvaskit/BUILD.bazel to see the use of the emscripten "wasm_cc_binary" rule, which depends on the "skia-core", "gms", and "tests" rule. Note that it only builds some of the gms as a proof of concept. - The other BUILD.bazel files. Some of these are not platform or feature dependent (e.g. pathops). Others are (e.g. gpu). - All other files. [1] https://docs.bazel.build/versions/4.2.1/skylark/config.html#user-defined-build-settings [2] https://github.com/emscripten-core/emsdk/pull/920 [3] In this CL, that's just the webgl one. [4] https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library.local_defines Change-Id: Ieecf9c106d5e3a6ae97d13d66be06b4b3c207089 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458637 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Owners-Override: Kevin Lubick <kjlubick@google.com>
2021-11-08 20:26:09 +00:00
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
[infra] Add hermetic toolchain for C/C++ using Clang+Musl This can successfully build a C library: bazel build --config=clang //third_party:libpng This can build and run a statically-linked executable: bazel test --config=clang //:bazel_test For more verbose compile and linking output, add the `--features diagnostic` flag to a Bazel command (see _make_diagnostic_flags() in toolchain/clang_toolchain_config.bzl. Similarly, a `--features print_search_dirs` can be used to show where clang is looking for libraries etc to link against. These features are made available for easier debugging. Suggested review order: - Read https://docs.bazel.build/versions/4.2.1/tutorial/cc-toolchain-config.html if unfamiliar with setting up C++ toolchains in Bazel - .bazelrc and WORKSPACE.bazel that configure use and download of the toolchain (Clang 13, musl 1.2.2) - toolchain/build_toolchain.bzl which downloads and assembles the toolchain (w/o installing anything on the host machine) - toolchain/BUILD.bazel and toolchain/*trampoline.sh to see the setup of the toolchain rules. - toolchain/clang_toolchain_config.bzl to see the configuration of the toolchain. Pay special attention to the various command line flags that are set. - See that tools/bazel_test.cc has made a new home in experimental/bazel_test/bazel_test.cpp, with a companion BUILD.bazel. Note the addition of some function calls that test use of the C++ standard library. The number being used to test the PNG library is the latest and greatest that verifies we are compiling the one brought in via DEPS (and not a local one). - third_party/* to see how png (and its dependent zlib) have been built. Pay special attention to the musl_compat hack to fix static linking (any idea what the real cause is?) - //BUILD.bazel to see definition of the bazel_test executable. Change-Id: I7b0922d0d45cb9be8df2fd5fa5a1f48492654d5f Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/461178 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2021-10-20 20:20:42 +00:00
[infra] Add initial Bazel rules and files These rules can be used to build our GMs on WASM+WebGL and libskia.a with just the CPU backend (and most other features turned off). This can be done with the following commands: - bazel build //modules/canvaskit:gm-bindings-wasm --gpu_backend=gl_backend --with_gl_standard=webgl_standard - bazel build :skia-core --config clang This pivots slightly from http://review.skia.org/463517 by using config_settings [1] instead of platforms for the optional features that we control. This pivot was suggested in [2] We have BUILD.bazel files in many of the subdirectories that specify filegroups for the appropriate files. In an effort to make //BUILD.bazel more readable, it is the responsibility of these subfolders to deal with conditionally including certain .h or .cpp files. This is done using select statements and config_settings or platform constraints as necessary. For example, src/gpu/BUILD.bazel will different private filegroups for each of the supported gpu backends [3] and a more-visible filegroup called "srcs" that has the right selection of the private files to be used for compilation. An effort has been made to avoid using glob() in our BUILD.bazel files. These file lists were made by using `ls -1` and some regex to add in quotes. We might want to make a helper script to assist with that, if necessary. To specify which options we have, the settings in //bazel/common_config_settings/BUILD.bazel have been redesigned. They make use of a macro `string_flag_with_values` that removes the boilerplate. Patchset 36 shows what the file looks like w/o the macro. The top level BUILD.bazel file will still need to use some logic to handle defines, because local_defines is a list of strings, not a list of labels [4]. Suggested Review Order: - WORKSPACE.bazel to see the new dependencies on the emsdk toolchain and bazel_skylib - bazel/common_config_settings/* to see the few settings defined (we have more to define, see BUILD.gn and //gn/skia.gni for ideas) - BUILD.bazel to see the "skia-core" cc_library rule. See also "gms" and "tests" - modules/canvaskit/BUILD.bazel to see the use of the emscripten "wasm_cc_binary" rule, which depends on the "skia-core", "gms", and "tests" rule. Note that it only builds some of the gms as a proof of concept. - The other BUILD.bazel files. Some of these are not platform or feature dependent (e.g. pathops). Others are (e.g. gpu). - All other files. [1] https://docs.bazel.build/versions/4.2.1/skylark/config.html#user-defined-build-settings [2] https://github.com/emscripten-core/emsdk/pull/920 [3] In this CL, that's just the webgl one. [4] https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library.local_defines Change-Id: Ieecf9c106d5e3a6ae97d13d66be06b4b3c207089 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458637 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Owners-Override: Kevin Lubick <kjlubick@google.com>
2021-11-08 20:26:09 +00:00
# See https://github.com/emscripten-core/emsdk/tree/85d27a4a2a60d591613a305b14ae438c2bb3ce11/bazel#setup-instructions
http_archive(
name = "emsdk",
Roll emsdk to 3.1.9 Rolled emsdk to the latest version to get the updated WebGPU wasm bindings to fix deprecated WebGPU API usage in the ganesh Dawn backend. The latest WebGPU headers also define the WGPU_WHOLE_MAP_SIZE constant which is necessary to land a workaround for skia:13266. * Roll emsdk to 3.1.9 * Fix Dawn backend to use the updated WebGPU API * Fix -Wunused-but-set-variable warnings Bug: skia:13220, skia:13266 Change-Id: I57ad39657c3013f384620302ab12a71ffc426c12 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534945 Commit-Queue: Arman Uguray <armansito@google.com> Reviewed-by: Kevin Lubick <kjlubick@google.com>
2022-04-28 21:32:16 +00:00
sha256 = "99de90a1827044c5430b926db947bcb266c8bdab1a0f20fe34a62431d9174376",
strip_prefix = "emsdk-3.1.9/bazel",
[bazel] Add mirrors to every external dependency. - We always download from https - All external assets have a primary and a mirror URL. - We prioritize the sources as follows: bazel mirror, github/original source, our mirror - There is a way (see build_toolchain) to test the sources from the mirrors (done before CL submission). This adds a utility to upload files to the mirror in a consistent, scripted way. It includes a way to copy in parts of our bazel files (e.g. debs_to_install from toolchain/build_toolchain.bzl) to update many things at once. Our Bazel mirror (gs://skia-world-readable/bazel) is a Content Addressable Storage system, where the file name is based on the sha256sum of the contents (the same hash that Bazel uses). All files in it should be publicly accessible. Change-Id: Ida8b8e07d27a0a557bc49467ebbc86c806cabbd3 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494478 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-01-13 15:19:38 +00:00
urls = [
Roll emsdk to 3.1.9 Rolled emsdk to the latest version to get the updated WebGPU wasm bindings to fix deprecated WebGPU API usage in the ganesh Dawn backend. The latest WebGPU headers also define the WGPU_WHOLE_MAP_SIZE constant which is necessary to land a workaround for skia:13266. * Roll emsdk to 3.1.9 * Fix Dawn backend to use the updated WebGPU API * Fix -Wunused-but-set-variable warnings Bug: skia:13220, skia:13266 Change-Id: I57ad39657c3013f384620302ab12a71ffc426c12 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534945 Commit-Queue: Arman Uguray <armansito@google.com> Reviewed-by: Kevin Lubick <kjlubick@google.com>
2022-04-28 21:32:16 +00:00
"https://github.com/emscripten-core/emsdk/archive/refs/tags/3.1.9.tar.gz",
"https://storage.googleapis.com/skia-world-readable/bazel/99de90a1827044c5430b926db947bcb266c8bdab1a0f20fe34a62431d9174376.tar.gz",
[bazel] Add mirrors to every external dependency. - We always download from https - All external assets have a primary and a mirror URL. - We prioritize the sources as follows: bazel mirror, github/original source, our mirror - There is a way (see build_toolchain) to test the sources from the mirrors (done before CL submission). This adds a utility to upload files to the mirror in a consistent, scripted way. It includes a way to copy in parts of our bazel files (e.g. debs_to_install from toolchain/build_toolchain.bzl) to update many things at once. Our Bazel mirror (gs://skia-world-readable/bazel) is a Content Addressable Storage system, where the file name is based on the sha256sum of the contents (the same hash that Bazel uses). All files in it should be publicly accessible. Change-Id: Ida8b8e07d27a0a557bc49467ebbc86c806cabbd3 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494478 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-01-13 15:19:38 +00:00
],
[infra] Add initial Bazel rules and files These rules can be used to build our GMs on WASM+WebGL and libskia.a with just the CPU backend (and most other features turned off). This can be done with the following commands: - bazel build //modules/canvaskit:gm-bindings-wasm --gpu_backend=gl_backend --with_gl_standard=webgl_standard - bazel build :skia-core --config clang This pivots slightly from http://review.skia.org/463517 by using config_settings [1] instead of platforms for the optional features that we control. This pivot was suggested in [2] We have BUILD.bazel files in many of the subdirectories that specify filegroups for the appropriate files. In an effort to make //BUILD.bazel more readable, it is the responsibility of these subfolders to deal with conditionally including certain .h or .cpp files. This is done using select statements and config_settings or platform constraints as necessary. For example, src/gpu/BUILD.bazel will different private filegroups for each of the supported gpu backends [3] and a more-visible filegroup called "srcs" that has the right selection of the private files to be used for compilation. An effort has been made to avoid using glob() in our BUILD.bazel files. These file lists were made by using `ls -1` and some regex to add in quotes. We might want to make a helper script to assist with that, if necessary. To specify which options we have, the settings in //bazel/common_config_settings/BUILD.bazel have been redesigned. They make use of a macro `string_flag_with_values` that removes the boilerplate. Patchset 36 shows what the file looks like w/o the macro. The top level BUILD.bazel file will still need to use some logic to handle defines, because local_defines is a list of strings, not a list of labels [4]. Suggested Review Order: - WORKSPACE.bazel to see the new dependencies on the emsdk toolchain and bazel_skylib - bazel/common_config_settings/* to see the few settings defined (we have more to define, see BUILD.gn and //gn/skia.gni for ideas) - BUILD.bazel to see the "skia-core" cc_library rule. See also "gms" and "tests" - modules/canvaskit/BUILD.bazel to see the use of the emscripten "wasm_cc_binary" rule, which depends on the "skia-core", "gms", and "tests" rule. Note that it only builds some of the gms as a proof of concept. - The other BUILD.bazel files. Some of these are not platform or feature dependent (e.g. pathops). Others are (e.g. gpu). - All other files. [1] https://docs.bazel.build/versions/4.2.1/skylark/config.html#user-defined-build-settings [2] https://github.com/emscripten-core/emsdk/pull/920 [3] In this CL, that's just the webgl one. [4] https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library.local_defines Change-Id: Ieecf9c106d5e3a6ae97d13d66be06b4b3c207089 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458637 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Owners-Override: Kevin Lubick <kjlubick@google.com>
2021-11-08 20:26:09 +00:00
)
load("@emsdk//:deps.bzl", emsdk_deps = "deps")
[bazel] Make custom karma_test rule Run the tests in headless mode and output the logs bazel test :hello_world --test_output=all Start up a visible web browser with the karma test driver (need to go to Debug tab to actually run tests) bazel run :hello_world Suggested review order - package.json to see the karma dependencies to run jasmine tests on chrome and firefox. - WORKSPACE.bazel to see how the packages listed in package.json and package-lock.json are downloaded into the Bazel sandbox/cache via the npm_install rule. As mentioned in the package.json comment, the version of build_bazel_rules_nodejs which emscripten uses [1] is 4.4.1 and if we tried to install it ourselves, that installation will be ignored. We also bring in hermetic browsers via io_bazel_rules_webtesting. - bazel/karma_test.bzl which defines a new rule _karma_test and a macro karma_test which joins the new rule with an existing web_test rule to run it on a hermetic browser which Bazel downloads. This rule takes heavy inspiration from @bazel/concatjs [2], but is much simpler and lets us configure more things (e.g. proxies, so we can work with test_on_env). - karma.bazel.js, which is a pretty ordinary looking karma configuration file [2] with effectively a JS macro BAZEL_APPLY_SETTINGS. JS doesn't have a preprocessor or actual macros, but this string will be replaced by the JS code in karma_test.bzl which will set correct filepaths for Bazel content. - All other files. [1] https://github.com/emscripten-core/emsdk/blob/c33c7be17f047355aa13a59f62a05100f9ff3257/bazel/deps.bzl#L10 [2] https://github.com/bazelbuild/rules_nodejs/blob/700b7a3c5f97f2877320e6e699892ee706f85269/packages/concatjs/web_test/karma_web_test.bzl#L318 [3] http://karma-runner.github.io/6.3/config/configuration-file.html Change-Id: Id64c0a86d6be37d627762cef0beaaf23ad390ac1 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/509717 Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-02-23 14:02:11 +00:00
# One of the deps here is build_bazel_rules_nodejs, currently version 4.4.1
# If we try to install it ourselves after this, it won't work.
[infra] Add initial Bazel rules and files These rules can be used to build our GMs on WASM+WebGL and libskia.a with just the CPU backend (and most other features turned off). This can be done with the following commands: - bazel build //modules/canvaskit:gm-bindings-wasm --gpu_backend=gl_backend --with_gl_standard=webgl_standard - bazel build :skia-core --config clang This pivots slightly from http://review.skia.org/463517 by using config_settings [1] instead of platforms for the optional features that we control. This pivot was suggested in [2] We have BUILD.bazel files in many of the subdirectories that specify filegroups for the appropriate files. In an effort to make //BUILD.bazel more readable, it is the responsibility of these subfolders to deal with conditionally including certain .h or .cpp files. This is done using select statements and config_settings or platform constraints as necessary. For example, src/gpu/BUILD.bazel will different private filegroups for each of the supported gpu backends [3] and a more-visible filegroup called "srcs" that has the right selection of the private files to be used for compilation. An effort has been made to avoid using glob() in our BUILD.bazel files. These file lists were made by using `ls -1` and some regex to add in quotes. We might want to make a helper script to assist with that, if necessary. To specify which options we have, the settings in //bazel/common_config_settings/BUILD.bazel have been redesigned. They make use of a macro `string_flag_with_values` that removes the boilerplate. Patchset 36 shows what the file looks like w/o the macro. The top level BUILD.bazel file will still need to use some logic to handle defines, because local_defines is a list of strings, not a list of labels [4]. Suggested Review Order: - WORKSPACE.bazel to see the new dependencies on the emsdk toolchain and bazel_skylib - bazel/common_config_settings/* to see the few settings defined (we have more to define, see BUILD.gn and //gn/skia.gni for ideas) - BUILD.bazel to see the "skia-core" cc_library rule. See also "gms" and "tests" - modules/canvaskit/BUILD.bazel to see the use of the emscripten "wasm_cc_binary" rule, which depends on the "skia-core", "gms", and "tests" rule. Note that it only builds some of the gms as a proof of concept. - The other BUILD.bazel files. Some of these are not platform or feature dependent (e.g. pathops). Others are (e.g. gpu). - All other files. [1] https://docs.bazel.build/versions/4.2.1/skylark/config.html#user-defined-build-settings [2] https://github.com/emscripten-core/emsdk/pull/920 [3] In this CL, that's just the webgl one. [4] https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library.local_defines Change-Id: Ieecf9c106d5e3a6ae97d13d66be06b4b3c207089 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458637 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Owners-Override: Kevin Lubick <kjlubick@google.com>
2021-11-08 20:26:09 +00:00
emsdk_deps()
load("@emsdk//:emscripten_deps.bzl", emsdk_emscripten_deps = "emscripten_deps")
Roll emsdk to 3.1.9 Rolled emsdk to the latest version to get the updated WebGPU wasm bindings to fix deprecated WebGPU API usage in the ganesh Dawn backend. The latest WebGPU headers also define the WGPU_WHOLE_MAP_SIZE constant which is necessary to land a workaround for skia:13266. * Roll emsdk to 3.1.9 * Fix Dawn backend to use the updated WebGPU API * Fix -Wunused-but-set-variable warnings Bug: skia:13220, skia:13266 Change-Id: I57ad39657c3013f384620302ab12a71ffc426c12 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534945 Commit-Queue: Arman Uguray <armansito@google.com> Reviewed-by: Kevin Lubick <kjlubick@google.com>
2022-04-28 21:32:16 +00:00
emsdk_emscripten_deps(emscripten_version = "3.1.9")
[infra] Add initial Bazel rules and files These rules can be used to build our GMs on WASM+WebGL and libskia.a with just the CPU backend (and most other features turned off). This can be done with the following commands: - bazel build //modules/canvaskit:gm-bindings-wasm --gpu_backend=gl_backend --with_gl_standard=webgl_standard - bazel build :skia-core --config clang This pivots slightly from http://review.skia.org/463517 by using config_settings [1] instead of platforms for the optional features that we control. This pivot was suggested in [2] We have BUILD.bazel files in many of the subdirectories that specify filegroups for the appropriate files. In an effort to make //BUILD.bazel more readable, it is the responsibility of these subfolders to deal with conditionally including certain .h or .cpp files. This is done using select statements and config_settings or platform constraints as necessary. For example, src/gpu/BUILD.bazel will different private filegroups for each of the supported gpu backends [3] and a more-visible filegroup called "srcs" that has the right selection of the private files to be used for compilation. An effort has been made to avoid using glob() in our BUILD.bazel files. These file lists were made by using `ls -1` and some regex to add in quotes. We might want to make a helper script to assist with that, if necessary. To specify which options we have, the settings in //bazel/common_config_settings/BUILD.bazel have been redesigned. They make use of a macro `string_flag_with_values` that removes the boilerplate. Patchset 36 shows what the file looks like w/o the macro. The top level BUILD.bazel file will still need to use some logic to handle defines, because local_defines is a list of strings, not a list of labels [4]. Suggested Review Order: - WORKSPACE.bazel to see the new dependencies on the emsdk toolchain and bazel_skylib - bazel/common_config_settings/* to see the few settings defined (we have more to define, see BUILD.gn and //gn/skia.gni for ideas) - BUILD.bazel to see the "skia-core" cc_library rule. See also "gms" and "tests" - modules/canvaskit/BUILD.bazel to see the use of the emscripten "wasm_cc_binary" rule, which depends on the "skia-core", "gms", and "tests" rule. Note that it only builds some of the gms as a proof of concept. - The other BUILD.bazel files. Some of these are not platform or feature dependent (e.g. pathops). Others are (e.g. gpu). - All other files. [1] https://docs.bazel.build/versions/4.2.1/skylark/config.html#user-defined-build-settings [2] https://github.com/emscripten-core/emsdk/pull/920 [3] In this CL, that's just the webgl one. [4] https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library.local_defines Change-Id: Ieecf9c106d5e3a6ae97d13d66be06b4b3c207089 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458637 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Owners-Override: Kevin Lubick <kjlubick@google.com>
2021-11-08 20:26:09 +00:00
http_archive(
name = "bazel_skylib",
sha256 = "c6966ec828da198c5d9adbaa94c05e3a1c7f21bd012a0b29ba8ddbccb2c93b0d",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/bazel-skylib/releases/download/1.1.1/bazel-skylib-1.1.1.tar.gz",
[bazel] Add mirrors to every external dependency. - We always download from https - All external assets have a primary and a mirror URL. - We prioritize the sources as follows: bazel mirror, github/original source, our mirror - There is a way (see build_toolchain) to test the sources from the mirrors (done before CL submission). This adds a utility to upload files to the mirror in a consistent, scripted way. It includes a way to copy in parts of our bazel files (e.g. debs_to_install from toolchain/build_toolchain.bzl) to update many things at once. Our Bazel mirror (gs://skia-world-readable/bazel) is a Content Addressable Storage system, where the file name is based on the sha256sum of the contents (the same hash that Bazel uses). All files in it should be publicly accessible. Change-Id: Ida8b8e07d27a0a557bc49467ebbc86c806cabbd3 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494478 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-01-13 15:19:38 +00:00
"https://github.com/bazelbuild/bazel-skylib/releases/download/1.1.1/bazel-skylib-1.1.1.tar.gz",
[infra] Add initial Bazel rules and files These rules can be used to build our GMs on WASM+WebGL and libskia.a with just the CPU backend (and most other features turned off). This can be done with the following commands: - bazel build //modules/canvaskit:gm-bindings-wasm --gpu_backend=gl_backend --with_gl_standard=webgl_standard - bazel build :skia-core --config clang This pivots slightly from http://review.skia.org/463517 by using config_settings [1] instead of platforms for the optional features that we control. This pivot was suggested in [2] We have BUILD.bazel files in many of the subdirectories that specify filegroups for the appropriate files. In an effort to make //BUILD.bazel more readable, it is the responsibility of these subfolders to deal with conditionally including certain .h or .cpp files. This is done using select statements and config_settings or platform constraints as necessary. For example, src/gpu/BUILD.bazel will different private filegroups for each of the supported gpu backends [3] and a more-visible filegroup called "srcs" that has the right selection of the private files to be used for compilation. An effort has been made to avoid using glob() in our BUILD.bazel files. These file lists were made by using `ls -1` and some regex to add in quotes. We might want to make a helper script to assist with that, if necessary. To specify which options we have, the settings in //bazel/common_config_settings/BUILD.bazel have been redesigned. They make use of a macro `string_flag_with_values` that removes the boilerplate. Patchset 36 shows what the file looks like w/o the macro. The top level BUILD.bazel file will still need to use some logic to handle defines, because local_defines is a list of strings, not a list of labels [4]. Suggested Review Order: - WORKSPACE.bazel to see the new dependencies on the emsdk toolchain and bazel_skylib - bazel/common_config_settings/* to see the few settings defined (we have more to define, see BUILD.gn and //gn/skia.gni for ideas) - BUILD.bazel to see the "skia-core" cc_library rule. See also "gms" and "tests" - modules/canvaskit/BUILD.bazel to see the use of the emscripten "wasm_cc_binary" rule, which depends on the "skia-core", "gms", and "tests" rule. Note that it only builds some of the gms as a proof of concept. - The other BUILD.bazel files. Some of these are not platform or feature dependent (e.g. pathops). Others are (e.g. gpu). - All other files. [1] https://docs.bazel.build/versions/4.2.1/skylark/config.html#user-defined-build-settings [2] https://github.com/emscripten-core/emsdk/pull/920 [3] In this CL, that's just the webgl one. [4] https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library.local_defines Change-Id: Ieecf9c106d5e3a6ae97d13d66be06b4b3c207089 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458637 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Owners-Override: Kevin Lubick <kjlubick@google.com>
2021-11-08 20:26:09 +00:00
],
)
load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
bazel_skylib_workspace()
[canvaskit] Add Freetype/Fonts to Bazel Build This re-works src/ports/BUILD.bazel to work like our other BUILD files, i.e. one rule "srcs" that brings in the necessary private filegroups. To work around an abort with LLVM [1], we have to go back to an earlier version of emscripten (temporarily?). Future work should look at using transitions [2] to allow various executables (e.g. CanvasKit, DM) to set their own set of Bazel flags, w/o the build invokers having to specify them. These transitions might be able to handle more complex cases that we currently use if statements in GN to deal with. The Freetype build rule was created by taking the BUILD.gn rule, adding in all the sources listed there and then playing compile-whack-a-mole to add in all the headers and included .c files. Suggested Review Order: - third_party/BUILD.bazel to see freetype build rules - bazel/common_config_settings/ to see treatment of fontmgr like codecs (many possible) and fontmgr_factory (only one). - src/ports/BUILD.bazel - BUILD.bazel - modules/canvaskit/BUILD.bazel. Take note of the gen_rule that calls tools/embed_resources.py to produce the .cpp file containing the embedded font data. - Everything else. [1] https://github.com/emscripten-core/emscripten/issues/15528 [2] https://github.com/bazelbuild/examples/tree/main/rules/starlark_configurations/cc_binary_selectable_copts Bug: skia:12541 Change-Id: I08dab82a901d80507007b354ca20cbfad2c2388f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471636 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2021-11-16 19:09:44 +00:00
[bazel] Add RBE support using hermetic Linux Clang toolchain 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>
2022-03-25 18:59:33 +00:00
http_archive(
name = "bazel_toolchains",
sha256 = "e52789d4e89c3e2dc0e3446a9684626a626b6bec3fde787d70bae37c6ebcc47f",
strip_prefix = "bazel-toolchains-5.1.1",
urls = [
"https://github.com/bazelbuild/bazel-toolchains/archive/refs/tags/v5.1.1.tar.gz",
"https://storage.googleapis.com/skia-world-readable/bazel/e52789d4e89c3e2dc0e3446a9684626a626b6bec3fde787d70bae37c6ebcc47f.tar.gz",
],
)
load("@bazel_toolchains//repositories:repositories.bzl", bazel_toolchains_repositories = "repositories")
bazel_toolchains_repositories()
[bazel] Use hermetic Python with jinja2+MarkupSafe The file generation logic that dawn [1] uses to make some source files requires jinja2, which also requires MarkupSafe. The GN build handles this by specifying those repos in DEPS, checking them out at a certain git hash, and then providing them via a command line arg [2]. We do not have to do it this way in Bazel to have reproducible builds. This CL specifies an exact version (verified by sha256) of those two deps and then uses a hermetic version of Python 3.9 to run all py_binary commands. Previously, we would rely on the system Python (and installed libraries). That happened to work on my machine, but not on other machines without jinja2 and MarkupSafe installed. After this CL, it should work on machines that do not have python even installed. I chose the same jinja2 version used by Dawn [3], which was 2.11.3. Then I chose the newest version of MarkupSafe that was compatible with jinja2 (2.0.1). If we have other python scripts that need external deps, we should be able to specify them in the py_binary that needs them and in requirements.txt. Then, the pip_install() step in WORKSPACE.bazel will download them and make them available. [1] https://dawn.googlesource.com/dawn.git/+/refs/heads/main/docs/dawn/overview.md [2] https://dawn.googlesource.com/dawn.git/+/e45ff6a4b3c2f06dade68ec0f01ddc3bfd70c282/generator/generator_lib.gni#77 [3] https://chromium.googlesource.com/chromium/src/third_party/jinja2/+/ee69aa00ee8536f61db6a451f3858745cf587de6 Change-Id: I3d0074f3003de179400e239e00107c34f35f4901 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524217 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-03-25 16:36:17 +00:00
#######################################################################################
# Python
#######################################################################################
# https://github.com/bazelbuild/rules_python
[canvaskit] Add Freetype/Fonts to Bazel Build This re-works src/ports/BUILD.bazel to work like our other BUILD files, i.e. one rule "srcs" that brings in the necessary private filegroups. To work around an abort with LLVM [1], we have to go back to an earlier version of emscripten (temporarily?). Future work should look at using transitions [2] to allow various executables (e.g. CanvasKit, DM) to set their own set of Bazel flags, w/o the build invokers having to specify them. These transitions might be able to handle more complex cases that we currently use if statements in GN to deal with. The Freetype build rule was created by taking the BUILD.gn rule, adding in all the sources listed there and then playing compile-whack-a-mole to add in all the headers and included .c files. Suggested Review Order: - third_party/BUILD.bazel to see freetype build rules - bazel/common_config_settings/ to see treatment of fontmgr like codecs (many possible) and fontmgr_factory (only one). - src/ports/BUILD.bazel - BUILD.bazel - modules/canvaskit/BUILD.bazel. Take note of the gen_rule that calls tools/embed_resources.py to produce the .cpp file containing the embedded font data. - Everything else. [1] https://github.com/emscripten-core/emscripten/issues/15528 [2] https://github.com/bazelbuild/examples/tree/main/rules/starlark_configurations/cc_binary_selectable_copts Bug: skia:12541 Change-Id: I08dab82a901d80507007b354ca20cbfad2c2388f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471636 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2021-11-16 19:09:44 +00:00
http_archive(
name = "rules_python",
[bazel] Use hermetic Python with jinja2+MarkupSafe The file generation logic that dawn [1] uses to make some source files requires jinja2, which also requires MarkupSafe. The GN build handles this by specifying those repos in DEPS, checking them out at a certain git hash, and then providing them via a command line arg [2]. We do not have to do it this way in Bazel to have reproducible builds. This CL specifies an exact version (verified by sha256) of those two deps and then uses a hermetic version of Python 3.9 to run all py_binary commands. Previously, we would rely on the system Python (and installed libraries). That happened to work on my machine, but not on other machines without jinja2 and MarkupSafe installed. After this CL, it should work on machines that do not have python even installed. I chose the same jinja2 version used by Dawn [3], which was 2.11.3. Then I chose the newest version of MarkupSafe that was compatible with jinja2 (2.0.1). If we have other python scripts that need external deps, we should be able to specify them in the py_binary that needs them and in requirements.txt. Then, the pip_install() step in WORKSPACE.bazel will download them and make them available. [1] https://dawn.googlesource.com/dawn.git/+/refs/heads/main/docs/dawn/overview.md [2] https://dawn.googlesource.com/dawn.git/+/e45ff6a4b3c2f06dade68ec0f01ddc3bfd70c282/generator/generator_lib.gni#77 [3] https://chromium.googlesource.com/chromium/src/third_party/jinja2/+/ee69aa00ee8536f61db6a451f3858745cf587de6 Change-Id: I3d0074f3003de179400e239e00107c34f35f4901 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524217 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-03-25 16:36:17 +00:00
sha256 = "9fcf91dbcc31fde6d1edb15f117246d912c33c36f44cf681976bd886538deba6",
strip_prefix = "rules_python-0.8.0",
[bazel] Add mirrors to every external dependency. - We always download from https - All external assets have a primary and a mirror URL. - We prioritize the sources as follows: bazel mirror, github/original source, our mirror - There is a way (see build_toolchain) to test the sources from the mirrors (done before CL submission). This adds a utility to upload files to the mirror in a consistent, scripted way. It includes a way to copy in parts of our bazel files (e.g. debs_to_install from toolchain/build_toolchain.bzl) to update many things at once. Our Bazel mirror (gs://skia-world-readable/bazel) is a Content Addressable Storage system, where the file name is based on the sha256sum of the contents (the same hash that Bazel uses). All files in it should be publicly accessible. Change-Id: Ida8b8e07d27a0a557bc49467ebbc86c806cabbd3 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494478 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-01-13 15:19:38 +00:00
urls = [
[bazel] Use hermetic Python with jinja2+MarkupSafe The file generation logic that dawn [1] uses to make some source files requires jinja2, which also requires MarkupSafe. The GN build handles this by specifying those repos in DEPS, checking them out at a certain git hash, and then providing them via a command line arg [2]. We do not have to do it this way in Bazel to have reproducible builds. This CL specifies an exact version (verified by sha256) of those two deps and then uses a hermetic version of Python 3.9 to run all py_binary commands. Previously, we would rely on the system Python (and installed libraries). That happened to work on my machine, but not on other machines without jinja2 and MarkupSafe installed. After this CL, it should work on machines that do not have python even installed. I chose the same jinja2 version used by Dawn [3], which was 2.11.3. Then I chose the newest version of MarkupSafe that was compatible with jinja2 (2.0.1). If we have other python scripts that need external deps, we should be able to specify them in the py_binary that needs them and in requirements.txt. Then, the pip_install() step in WORKSPACE.bazel will download them and make them available. [1] https://dawn.googlesource.com/dawn.git/+/refs/heads/main/docs/dawn/overview.md [2] https://dawn.googlesource.com/dawn.git/+/e45ff6a4b3c2f06dade68ec0f01ddc3bfd70c282/generator/generator_lib.gni#77 [3] https://chromium.googlesource.com/chromium/src/third_party/jinja2/+/ee69aa00ee8536f61db6a451f3858745cf587de6 Change-Id: I3d0074f3003de179400e239e00107c34f35f4901 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524217 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-03-25 16:36:17 +00:00
"https://github.com/bazelbuild/rules_python/archive/refs/tags/0.8.0.tar.gz",
"https://storage.googleapis.com/skia-world-readable/bazel/9fcf91dbcc31fde6d1edb15f117246d912c33c36f44cf681976bd886538deba6.tar.gz",
[bazel] Add mirrors to every external dependency. - We always download from https - All external assets have a primary and a mirror URL. - We prioritize the sources as follows: bazel mirror, github/original source, our mirror - There is a way (see build_toolchain) to test the sources from the mirrors (done before CL submission). This adds a utility to upload files to the mirror in a consistent, scripted way. It includes a way to copy in parts of our bazel files (e.g. debs_to_install from toolchain/build_toolchain.bzl) to update many things at once. Our Bazel mirror (gs://skia-world-readable/bazel) is a Content Addressable Storage system, where the file name is based on the sha256sum of the contents (the same hash that Bazel uses). All files in it should be publicly accessible. Change-Id: Ida8b8e07d27a0a557bc49467ebbc86c806cabbd3 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494478 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-01-13 15:19:38 +00:00
],
[canvaskit] Add Freetype/Fonts to Bazel Build This re-works src/ports/BUILD.bazel to work like our other BUILD files, i.e. one rule "srcs" that brings in the necessary private filegroups. To work around an abort with LLVM [1], we have to go back to an earlier version of emscripten (temporarily?). Future work should look at using transitions [2] to allow various executables (e.g. CanvasKit, DM) to set their own set of Bazel flags, w/o the build invokers having to specify them. These transitions might be able to handle more complex cases that we currently use if statements in GN to deal with. The Freetype build rule was created by taking the BUILD.gn rule, adding in all the sources listed there and then playing compile-whack-a-mole to add in all the headers and included .c files. Suggested Review Order: - third_party/BUILD.bazel to see freetype build rules - bazel/common_config_settings/ to see treatment of fontmgr like codecs (many possible) and fontmgr_factory (only one). - src/ports/BUILD.bazel - BUILD.bazel - modules/canvaskit/BUILD.bazel. Take note of the gen_rule that calls tools/embed_resources.py to produce the .cpp file containing the embedded font data. - Everything else. [1] https://github.com/emscripten-core/emscripten/issues/15528 [2] https://github.com/bazelbuild/examples/tree/main/rules/starlark_configurations/cc_binary_selectable_copts Bug: skia:12541 Change-Id: I08dab82a901d80507007b354ca20cbfad2c2388f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471636 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2021-11-16 19:09:44 +00:00
)
[bazel] Add go/gazelle to WORKSPACE and use c++ extension. This adds a simple go program to test the installed go toolchain, and a Make rule to codify the arguments to our gazelle binary, built with extensions. I could not figure out how to get the .json file to work with the gazelle() Bazel rule, but this works ok for now. Bug: skia:12541 Change-Id: I5067b15c7518951aeb69559d3871799d3b5745f4 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/475716 Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2021-11-23 19:58:20 +00:00
[bazel] Use hermetic Python with jinja2+MarkupSafe The file generation logic that dawn [1] uses to make some source files requires jinja2, which also requires MarkupSafe. The GN build handles this by specifying those repos in DEPS, checking them out at a certain git hash, and then providing them via a command line arg [2]. We do not have to do it this way in Bazel to have reproducible builds. This CL specifies an exact version (verified by sha256) of those two deps and then uses a hermetic version of Python 3.9 to run all py_binary commands. Previously, we would rely on the system Python (and installed libraries). That happened to work on my machine, but not on other machines without jinja2 and MarkupSafe installed. After this CL, it should work on machines that do not have python even installed. I chose the same jinja2 version used by Dawn [3], which was 2.11.3. Then I chose the newest version of MarkupSafe that was compatible with jinja2 (2.0.1). If we have other python scripts that need external deps, we should be able to specify them in the py_binary that needs them and in requirements.txt. Then, the pip_install() step in WORKSPACE.bazel will download them and make them available. [1] https://dawn.googlesource.com/dawn.git/+/refs/heads/main/docs/dawn/overview.md [2] https://dawn.googlesource.com/dawn.git/+/e45ff6a4b3c2f06dade68ec0f01ddc3bfd70c282/generator/generator_lib.gni#77 [3] https://chromium.googlesource.com/chromium/src/third_party/jinja2/+/ee69aa00ee8536f61db6a451f3858745cf587de6 Change-Id: I3d0074f3003de179400e239e00107c34f35f4901 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524217 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-03-25 16:36:17 +00:00
# This sets up a hermetic python3, rather than depending on what is installed.
load("@rules_python//python:repositories.bzl", "python_register_toolchains")
python_register_toolchains(
name = "python3_9",
# https://github.com/bazelbuild/rules_python/blob/main/python/versions.bzl
python_version = "3.9",
)
load("@python3_9//:defs.bzl", "interpreter")
load("@rules_python//python:pip.bzl", "pip_install")
pip_install(
name = "py_deps",
python_interpreter_target = interpreter,
requirements = "//:requirements.txt",
)
[bazel] Add go/gazelle to WORKSPACE and use c++ extension. This adds a simple go program to test the installed go toolchain, and a Make rule to codify the arguments to our gazelle binary, built with extensions. I could not figure out how to get the .json file to work with the gazelle() Bazel rule, but this works ok for now. Bug: skia:12541 Change-Id: I5067b15c7518951aeb69559d3871799d3b5745f4 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/475716 Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2021-11-23 19:58:20 +00:00
#######################################################################################
# Gazelle
#######################################################################################
http_archive(
name = "io_bazel_rules_go",
sha256 = "2b1641428dff9018f9e85c0384f03ec6c10660d935b750e3fa1492a281a53b0f",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.29.0/rules_go-v0.29.0.zip",
"https://github.com/bazelbuild/rules_go/releases/download/v0.29.0/rules_go-v0.29.0.zip",
],
)
http_archive(
name = "bazel_gazelle",
sha256 = "de69a09dc70417580aabf20a28619bb3ef60d038470c7cf8442fafcf627c21cb",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.24.0/bazel-gazelle-v0.24.0.tar.gz",
"https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.24.0/bazel-gazelle-v0.24.0.tar.gz",
],
)
load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies")
load("//:go_repositories.bzl", "go_repositories")
# gazelle:repository_macro go_repositories.bzl%go_repositories
go_repositories()
go_rules_dependencies()
go_register_toolchains(version = "1.17.2")
gazelle_dependencies(go_repository_default_config = "//:WORKSPACE.bazel")
[bazel] Make custom karma_test rule Run the tests in headless mode and output the logs bazel test :hello_world --test_output=all Start up a visible web browser with the karma test driver (need to go to Debug tab to actually run tests) bazel run :hello_world Suggested review order - package.json to see the karma dependencies to run jasmine tests on chrome and firefox. - WORKSPACE.bazel to see how the packages listed in package.json and package-lock.json are downloaded into the Bazel sandbox/cache via the npm_install rule. As mentioned in the package.json comment, the version of build_bazel_rules_nodejs which emscripten uses [1] is 4.4.1 and if we tried to install it ourselves, that installation will be ignored. We also bring in hermetic browsers via io_bazel_rules_webtesting. - bazel/karma_test.bzl which defines a new rule _karma_test and a macro karma_test which joins the new rule with an existing web_test rule to run it on a hermetic browser which Bazel downloads. This rule takes heavy inspiration from @bazel/concatjs [2], but is much simpler and lets us configure more things (e.g. proxies, so we can work with test_on_env). - karma.bazel.js, which is a pretty ordinary looking karma configuration file [2] with effectively a JS macro BAZEL_APPLY_SETTINGS. JS doesn't have a preprocessor or actual macros, but this string will be replaced by the JS code in karma_test.bzl which will set correct filepaths for Bazel content. - All other files. [1] https://github.com/emscripten-core/emsdk/blob/c33c7be17f047355aa13a59f62a05100f9ff3257/bazel/deps.bzl#L10 [2] https://github.com/bazelbuild/rules_nodejs/blob/700b7a3c5f97f2877320e6e699892ee706f85269/packages/concatjs/web_test/karma_web_test.bzl#L318 [3] http://karma-runner.github.io/6.3/config/configuration-file.html Change-Id: Id64c0a86d6be37d627762cef0beaaf23ad390ac1 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/509717 Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-02-23 14:02:11 +00:00
[bazel] Use bazel to build task drivers One very important, but agonizing to discover, change was to go_repositories.bzl. Without it, we see cryptic errors like: external/org_chromium_go_luci/cipd/api/cipd/v1/BUILD.bazel:22:17: no such package '@org_chromium_go_luci//go.chromium.org/luci/cipd/api/cipd/v1': BUILD file not found in directory 'go.chromium.org/luci/cipd/api/cipd/v1' of external repository @org_chromium_go_luci. Add a BUILD file to a directory to mark it as a package. and referenced by '@org_chromium_go_luci//cipd/api/cipd/v1:api_go_proto' The rest of these changes are very similar to https://skia-review.googlesource.com/c/buildbot/+/514074 which also has justification for the use of task drivers, even in a Bazel-driven world. All the BUILD.bazel files under infra/bots/task_drivers were generated by Gazelle. Note that the infra/bots/BUILD.bazel can happily build and package up the task drivers from the infra repo. The old build_task_drivers tasks did this too, because we have some task drivers that are used in both repos. Change-Id: I13c46c62bc7a6a4bfe7935b28efbfb34caabb6f2 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/515296 Reviewed-by: Eric Boren <borenet@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-03-03 15:42:57 +00:00
# Because the skia infra repo has a dependency on google.golang.org/grpc (aka
# @org_golang_google_grpc), we need to have this library available to build protos.
# https://github.com/bazelbuild/rules_go#protobuf-and-grpc
http_archive(
name = "com_google_protobuf",
sha256 = "d0f5f605d0d656007ce6c8b5a82df3037e1d8fe8b121ed42e536f569dec16113",
strip_prefix = "protobuf-3.14.0",
urls = [
"https://mirror.bazel.build/github.com/protocolbuffers/protobuf/archive/v3.14.0.tar.gz",
"https://github.com/protocolbuffers/protobuf/archive/v3.14.0.tar.gz",
],
)
load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
protobuf_deps()
[bazel] Make custom karma_test rule Run the tests in headless mode and output the logs bazel test :hello_world --test_output=all Start up a visible web browser with the karma test driver (need to go to Debug tab to actually run tests) bazel run :hello_world Suggested review order - package.json to see the karma dependencies to run jasmine tests on chrome and firefox. - WORKSPACE.bazel to see how the packages listed in package.json and package-lock.json are downloaded into the Bazel sandbox/cache via the npm_install rule. As mentioned in the package.json comment, the version of build_bazel_rules_nodejs which emscripten uses [1] is 4.4.1 and if we tried to install it ourselves, that installation will be ignored. We also bring in hermetic browsers via io_bazel_rules_webtesting. - bazel/karma_test.bzl which defines a new rule _karma_test and a macro karma_test which joins the new rule with an existing web_test rule to run it on a hermetic browser which Bazel downloads. This rule takes heavy inspiration from @bazel/concatjs [2], but is much simpler and lets us configure more things (e.g. proxies, so we can work with test_on_env). - karma.bazel.js, which is a pretty ordinary looking karma configuration file [2] with effectively a JS macro BAZEL_APPLY_SETTINGS. JS doesn't have a preprocessor or actual macros, but this string will be replaced by the JS code in karma_test.bzl which will set correct filepaths for Bazel content. - All other files. [1] https://github.com/emscripten-core/emsdk/blob/c33c7be17f047355aa13a59f62a05100f9ff3257/bazel/deps.bzl#L10 [2] https://github.com/bazelbuild/rules_nodejs/blob/700b7a3c5f97f2877320e6e699892ee706f85269/packages/concatjs/web_test/karma_web_test.bzl#L318 [3] http://karma-runner.github.io/6.3/config/configuration-file.html Change-Id: Id64c0a86d6be37d627762cef0beaaf23ad390ac1 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/509717 Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-02-23 14:02:11 +00:00
###################################################
# JavaScript / TypeScript rules and dependencies. #
###################################################
# The npm_install rule runs anytime the package.json or package-lock.json file changes. It also
# extracts any Bazel rules distributed in an npm package.
load("@build_bazel_rules_nodejs//:index.bzl", "npm_install")
# Manages the node_modules directory.
npm_install(
name = "npm",
package_json = "//:package.json",
package_lock_json = "//:package-lock.json",
)
# io_bazel_rules_webtesting allows us to download browsers in a hermetic, repeatable way. This
# currently includes Chromium and Firefox. Note that the version on this does not necessarily
# match the version below of the browsers-X.Y.Z below that is available.
http_archive(
name = "io_bazel_rules_webtesting",
sha256 = "e9abb7658b6a129740c0b3ef6f5a2370864e102a5ba5ffca2cea565829ed825a",
urls = [
"https://github.com/bazelbuild/rules_webtesting/releases/download/0.3.5/rules_webtesting.tar.gz",
"https://storage.googleapis.com/skia-world-readable/bazel/e9abb7658b6a129740c0b3ef6f5a2370864e102a5ba5ffca2cea565829ed825a.tar.gz",
],
)
# https://github.com/bazelbuild/rules_webtesting/blob/e9cf17123068b1123c68219edf9b274bf057b9cc/web/versioned/browsers-0.3.3.bzl
load("@io_bazel_rules_webtesting//web/versioned:browsers-0.3.3.bzl", "browser_repositories")
browser_repositories(
chromium = True,
firefox = True,
)
[bazel] Add support for Dawn (via Vulkan) sk_app has existing support for Dawn on top of Vulkan, and this adds support to build //example:hello_world_dawn and get this to run on Linux. Dawn depends on Tint and abseil-cpp. Tint further depends on spirv_tools and spirv_headers (for writing to the SPIR-V format). Dawn and Tint only have GN and CMake support, so we need to make our Bazel rules for them (see //third_party/BUILD.bazel). abseil-cpp and the SPIR-V libraries have Bazel support, so we can just include them (see //WORKSPACE.bazel). It is important that @spirv_headers be called that exactly because @spirv_tools depends on it by that name. The hand-crafted cc_library rules for Dawn and Tint were produced by reading the appropriate GN files and using the parts necessary for a supporting Vulkan+Linux. If we use Dawn for other backends (e.g. WebGPU), we will need to expand the Bazel rules. One day, we might contribute the Bazel rules to Dawn and Tint so they can support them and avoid breaking us if new files are added. Suggested Review Order - bazel/common_config_settings/BUILD.bazel to see introduction of new select-able option "has_gpu_backend" which cleans up some of our code that is enabled for any GPU backend. - src/*/BUILD.bazel to see has_gpu_backend rolled out. - WORKSPACE.bazel to see DEPS declared there (using the files in third_party/externals, which are brought in via tools/git-sync-deps). - third_party/BUILD.bazel which adds Dawn and Tint rules. It may be helpful to look in third_party/externals for the Dawn [1] and Tint [2] GN files. Especially interesting are the Python scripts [3] Dawn uses to generate some header and source files. - All other files. [1] https://dawn.googlesource.com/dawn/+/d9f22ce0346b222759d5510be3d1cd93caa5ab86/src/dawn/native/BUILD.gn#183 [2] https://dawn.googlesource.com/tint/+/453d5ae84ec30ab51ac592c13d472412ae8b5fc9/src/tint/BUILD.gn#174 [3] https://dawn.googlesource.com/dawn/+/d9f22ce0346b222759d5510be3d1cd93caa5ab86/generator/dawn_json_generator.py#774 Change-Id: Ied5b162045d8e841b9666457f0158457e2b078d4 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516996 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Greg Daniel <egdaniel@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-03-21 17:06:32 +00:00
###################################################
# External C++ deps with Bazel support #
###################################################
[bazel] Point to vk_mem_alloc from DEPS To make it easier to use the G3 version of this dep, we make a reference to it in the WORKSPACE.bazel, so we can refer to this external dep with the @ notation. I would like to do this for all of our third party deps, but one at a time. Change-Id: I03e0beca124225e0faf1232278dae641da8a3e4d Bug: skia:13240, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535358 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-04-29 12:23:25 +00:00
# https://bazel.build/reference/be/workspace#local_repository
[bazel] Add support for Dawn (via Vulkan) sk_app has existing support for Dawn on top of Vulkan, and this adds support to build //example:hello_world_dawn and get this to run on Linux. Dawn depends on Tint and abseil-cpp. Tint further depends on spirv_tools and spirv_headers (for writing to the SPIR-V format). Dawn and Tint only have GN and CMake support, so we need to make our Bazel rules for them (see //third_party/BUILD.bazel). abseil-cpp and the SPIR-V libraries have Bazel support, so we can just include them (see //WORKSPACE.bazel). It is important that @spirv_headers be called that exactly because @spirv_tools depends on it by that name. The hand-crafted cc_library rules for Dawn and Tint were produced by reading the appropriate GN files and using the parts necessary for a supporting Vulkan+Linux. If we use Dawn for other backends (e.g. WebGPU), we will need to expand the Bazel rules. One day, we might contribute the Bazel rules to Dawn and Tint so they can support them and avoid breaking us if new files are added. Suggested Review Order - bazel/common_config_settings/BUILD.bazel to see introduction of new select-able option "has_gpu_backend" which cleans up some of our code that is enabled for any GPU backend. - src/*/BUILD.bazel to see has_gpu_backend rolled out. - WORKSPACE.bazel to see DEPS declared there (using the files in third_party/externals, which are brought in via tools/git-sync-deps). - third_party/BUILD.bazel which adds Dawn and Tint rules. It may be helpful to look in third_party/externals for the Dawn [1] and Tint [2] GN files. Especially interesting are the Python scripts [3] Dawn uses to generate some header and source files. - All other files. [1] https://dawn.googlesource.com/dawn/+/d9f22ce0346b222759d5510be3d1cd93caa5ab86/src/dawn/native/BUILD.gn#183 [2] https://dawn.googlesource.com/tint/+/453d5ae84ec30ab51ac592c13d472412ae8b5fc9/src/tint/BUILD.gn#174 [3] https://dawn.googlesource.com/dawn/+/d9f22ce0346b222759d5510be3d1cd93caa5ab86/generator/dawn_json_generator.py#774 Change-Id: Ied5b162045d8e841b9666457f0158457e2b078d4 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516996 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Greg Daniel <egdaniel@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-03-21 17:06:32 +00:00
local_repository(
name = "abseil_cpp",
path = "third_party/externals/abseil-cpp",
)
local_repository(
name = "spirv_tools",
path = "third_party/externals/spirv-tools",
)
local_repository(
# This name is important because spirv_tools expects @spirv_headers to exist by that name.
name = "spirv_headers",
path = "third_party/externals/spirv-headers",
)
[bazel] Point to vk_mem_alloc from DEPS To make it easier to use the G3 version of this dep, we make a reference to it in the WORKSPACE.bazel, so we can refer to this external dep with the @ notation. I would like to do this for all of our third party deps, but one at a time. Change-Id: I03e0beca124225e0faf1232278dae641da8a3e4d Bug: skia:13240, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535358 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-04-29 12:23:25 +00:00
[bazel] Move Dawn BUILD.bazel to third_party/bazel Rather than having a monolithic third_party/BUILD.bazel, this moves our Dawn rules to their own subdirectory and makes it callable via @dawn instead of //third_party/dawn. This will help with the G3 roll and make our rules more organized in general. This also rolls Dawn Roll Dawn from ab9757036bd6 to e831fb61046b (22 revisions) https://dawn.googlesource.com/dawn.git/+log/ab9757036bd6..e831fb61046b Suggested Review Order: - WORKSPACE.bazel, where we define @dawn and its deps (@vulkan_headers and @vulkan_tools). I initially thought I needed to define all of Dawn's deps in the workspace_file_content for new_local_repository, but that WORKSPACE file is ignored when building Skia rules. - third_party/dawn/BUILD.bazel, the contents of which were copied from //third_party/BUILD.bazel and modified largely via find-and-replace to point to files relative to //third_party/externals/dawn. One exception is the cpu_wasm config_setting because @dawn isn't able to see Skia's //bazel/macros.bzl. - All other files Change-Id: Ib2d7bc972ef00b6b68370ce5c2839ffb70ed9a2f Bug: skia:12541, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538638 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-05-16 12:59:45 +00:00
###############################################################################
# External C++ deps with NO Bazel support #
# In this case, we need to supply a BUILD file which exposes targets/files #
# we need. If these deps depend on other deps (e.g. @dawn -> @spirv_tools), #
# then we need to specify those here as well. The workspace_file_content is #
# generally ignored; external repos (i.e. the ones starting with @) will be #
# resolved with Skia's version of those repos, which is how Bazel avoids #
# multiple versions of the same project being compiled together. #
###############################################################################
[bazel] Point to vk_mem_alloc from DEPS To make it easier to use the G3 version of this dep, we make a reference to it in the WORKSPACE.bazel, so we can refer to this external dep with the @ notation. I would like to do this for all of our third party deps, but one at a time. Change-Id: I03e0beca124225e0faf1232278dae641da8a3e4d Bug: skia:13240, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535358 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-04-29 12:23:25 +00:00
# https://bazel.build/reference/be/workspace#new_local_repository
new_local_repository(
[bazel] Move zlib and libpng out of //third_party/BUILD.bazel I had to copy some config_settings out of //bazel/common_config_settings because these are now treated as separate entities and cannot see that file. For libpng, note that we use a genrule to create the pnglibconf.h instead of pointing to one somewhere else. This ended up being easier than other things I tried. Another approach would be to not depend on the version in third_party/externals, but to clone it via new_git_repository [1] and apply a patch that creates the configuration file. [1] https://bazel.build/rules/lib/repo/git#new_git_repository Bug: skia:12541 Change-Id: I9a284775dc0f2bdabb145518d5f0803c74fb99fa Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545368 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-05-31 20:22:31 +00:00
name = "dawn",
build_file = "bazel/external/dawn/BUILD.bazel",
path = "third_party/externals/dawn",
[bazel] Move Dawn BUILD.bazel to third_party/bazel Rather than having a monolithic third_party/BUILD.bazel, this moves our Dawn rules to their own subdirectory and makes it callable via @dawn instead of //third_party/dawn. This will help with the G3 roll and make our rules more organized in general. This also rolls Dawn Roll Dawn from ab9757036bd6 to e831fb61046b (22 revisions) https://dawn.googlesource.com/dawn.git/+log/ab9757036bd6..e831fb61046b Suggested Review Order: - WORKSPACE.bazel, where we define @dawn and its deps (@vulkan_headers and @vulkan_tools). I initially thought I needed to define all of Dawn's deps in the workspace_file_content for new_local_repository, but that WORKSPACE file is ignored when building Skia rules. - third_party/dawn/BUILD.bazel, the contents of which were copied from //third_party/BUILD.bazel and modified largely via find-and-replace to point to files relative to //third_party/externals/dawn. One exception is the cpu_wasm config_setting because @dawn isn't able to see Skia's //bazel/macros.bzl. - All other files Change-Id: Ib2d7bc972ef00b6b68370ce5c2839ffb70ed9a2f Bug: skia:12541, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538638 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-05-16 12:59:45 +00:00
workspace_file_content = "",
)
[bazel] Move remaining codec build rules to //bazel/external There are no functional changes to the rules, just a relocation. Change-Id: I90af5ec792fc54ce2978b0bbb1afd2c932e183b4 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545719 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-06-01 18:45:18 +00:00
new_local_repository(
name = "dng_sdk",
build_file = "bazel/external/dng_sdk/BUILD.bazel",
path = "third_party/externals/dng_sdk",
workspace_file_content = "",
)
[bazel] Add option for SkSVGCanvas (and expat third_party DEP) Our SVG code depends on our XML code which depends on expat. See also cl/457481999 Change-Id: I83b61f5d73570d0aa7e851a01ccd019b4b1019e4 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/553376 Reviewed-by: Florin Malita <fmalita@google.com>
2022-06-27 14:07:26 +00:00
new_local_repository(
name = "expat",
build_file = "bazel/external/expat/BUILD.bazel",
path = "third_party/externals/expat",
workspace_file_content = "",
)
[bazel] Move remaining codec build rules to //bazel/external There are no functional changes to the rules, just a relocation. Change-Id: I90af5ec792fc54ce2978b0bbb1afd2c932e183b4 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545719 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-06-01 18:45:18 +00:00
new_local_repository(
name = "libjpeg_turbo",
build_file = "bazel/external/libjpeg_turbo/BUILD.bazel",
path = "third_party/externals/libjpeg-turbo",
workspace_file_content = "",
)
[bazel] Move Dawn BUILD.bazel to third_party/bazel Rather than having a monolithic third_party/BUILD.bazel, this moves our Dawn rules to their own subdirectory and makes it callable via @dawn instead of //third_party/dawn. This will help with the G3 roll and make our rules more organized in general. This also rolls Dawn Roll Dawn from ab9757036bd6 to e831fb61046b (22 revisions) https://dawn.googlesource.com/dawn.git/+log/ab9757036bd6..e831fb61046b Suggested Review Order: - WORKSPACE.bazel, where we define @dawn and its deps (@vulkan_headers and @vulkan_tools). I initially thought I needed to define all of Dawn's deps in the workspace_file_content for new_local_repository, but that WORKSPACE file is ignored when building Skia rules. - third_party/dawn/BUILD.bazel, the contents of which were copied from //third_party/BUILD.bazel and modified largely via find-and-replace to point to files relative to //third_party/externals/dawn. One exception is the cpu_wasm config_setting because @dawn isn't able to see Skia's //bazel/macros.bzl. - All other files Change-Id: Ib2d7bc972ef00b6b68370ce5c2839ffb70ed9a2f Bug: skia:12541, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538638 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-05-16 12:59:45 +00:00
new_local_repository(
[bazel] Move zlib and libpng out of //third_party/BUILD.bazel I had to copy some config_settings out of //bazel/common_config_settings because these are now treated as separate entities and cannot see that file. For libpng, note that we use a genrule to create the pnglibconf.h instead of pointing to one somewhere else. This ended up being easier than other things I tried. Another approach would be to not depend on the version in third_party/externals, but to clone it via new_git_repository [1] and apply a patch that creates the configuration file. [1] https://bazel.build/rules/lib/repo/git#new_git_repository Bug: skia:12541 Change-Id: I9a284775dc0f2bdabb145518d5f0803c74fb99fa Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545368 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-05-31 20:22:31 +00:00
name = "libpng",
build_file = "bazel/external/libpng/BUILD.bazel",
path = "third_party/externals/libpng",
[bazel] Move Dawn BUILD.bazel to third_party/bazel Rather than having a monolithic third_party/BUILD.bazel, this moves our Dawn rules to their own subdirectory and makes it callable via @dawn instead of //third_party/dawn. This will help with the G3 roll and make our rules more organized in general. This also rolls Dawn Roll Dawn from ab9757036bd6 to e831fb61046b (22 revisions) https://dawn.googlesource.com/dawn.git/+log/ab9757036bd6..e831fb61046b Suggested Review Order: - WORKSPACE.bazel, where we define @dawn and its deps (@vulkan_headers and @vulkan_tools). I initially thought I needed to define all of Dawn's deps in the workspace_file_content for new_local_repository, but that WORKSPACE file is ignored when building Skia rules. - third_party/dawn/BUILD.bazel, the contents of which were copied from //third_party/BUILD.bazel and modified largely via find-and-replace to point to files relative to //third_party/externals/dawn. One exception is the cpu_wasm config_setting because @dawn isn't able to see Skia's //bazel/macros.bzl. - All other files Change-Id: Ib2d7bc972ef00b6b68370ce5c2839ffb70ed9a2f Bug: skia:12541, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538638 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-05-16 12:59:45 +00:00
workspace_file_content = "",
)
[bazel] Move remaining codec build rules to //bazel/external There are no functional changes to the rules, just a relocation. Change-Id: I90af5ec792fc54ce2978b0bbb1afd2c932e183b4 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545719 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-06-01 18:45:18 +00:00
new_local_repository(
name = "libwebp",
build_file = "bazel/external/libwebp/BUILD.bazel",
path = "third_party/externals/libwebp",
workspace_file_content = "",
)
Reland "Add Perfetto library (gn & bazel) and bare-bones SkPerfTrace class" This reverts commit d78d52a86fa3c646a96cc21a149a4e42467f2871. That reason this CL was reverted in the first place is that it broke the Android roller - perfetto.h could not be located. We now disable the use of perfetto for Android in the gn_to_bp.py script, so the roller should be good to go. Reason for revert: Relanding Original change's description: > Revert "Add Perfetto library (gn & bazel) and bare-bones SkPerfTrace class" > > This reverts commit bfc9b9484092e969664aed59c0bb410fecfc107e. > > Reason for revert: new dependency causing Android build error > > Original change's description: > > Add Perfetto library (gn & bazel) and bare-bones SkPerfTrace class > > > > First incremental step to incorporating Perfetto tracing into Skia, more CLs to follow > > > > NOTE: The presubmit check is failing. This appears to be due to the known issue where the presubmit check bugs out if the DEPS file is edited, which it was on this CL (modified to include Perfetto). > > > > Bug: skia:13303 > > Change-Id: I908be0392b520e8da14b34588b842bf6d955bd93 > > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543081 > > Reviewed-by: Greg Daniel <egdaniel@google.com> > > Commit-Queue: Nicolette Prevost <nicolettep@google.com> > > Bug: skia:13303 > Change-Id: Ia2b883bbab1f8fb4f3914b63104a39240cc60e86 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544239 > Reviewed-by: Tyler Denniston <tdenniston@google.com> > Auto-Submit: Tyler Denniston <tdenniston@google.com> > Reviewed-by: Nicolette Prevost <nicolettep@google.com> > Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> > Commit-Queue: Tyler Denniston <tdenniston@google.com> Bug: skia:13303 Change-Id: Ibd369b9c8c0e69fc9615fc05cf588ee4440c8ed5 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544244 Reviewed-by: Greg Daniel <egdaniel@google.com> Commit-Queue: Nicolette Prevost <nicolettep@google.com>
2022-06-14 20:42:28 +00:00
new_local_repository(
name = "perfetto",
build_file = "bazel/external/perfetto/BUILD.bazel",
path = "third_party/externals/perfetto",
workspace_file_content = "",
)
[bazel] Move remaining codec build rules to //bazel/external There are no functional changes to the rules, just a relocation. Change-Id: I90af5ec792fc54ce2978b0bbb1afd2c932e183b4 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545719 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-06-01 18:45:18 +00:00
new_local_repository(
name = "piex",
build_file = "bazel/external/piex/BUILD.bazel",
path = "third_party/externals/piex",
workspace_file_content = "",
)
[bazel] Move Dawn BUILD.bazel to third_party/bazel Rather than having a monolithic third_party/BUILD.bazel, this moves our Dawn rules to their own subdirectory and makes it callable via @dawn instead of //third_party/dawn. This will help with the G3 roll and make our rules more organized in general. This also rolls Dawn Roll Dawn from ab9757036bd6 to e831fb61046b (22 revisions) https://dawn.googlesource.com/dawn.git/+log/ab9757036bd6..e831fb61046b Suggested Review Order: - WORKSPACE.bazel, where we define @dawn and its deps (@vulkan_headers and @vulkan_tools). I initially thought I needed to define all of Dawn's deps in the workspace_file_content for new_local_repository, but that WORKSPACE file is ignored when building Skia rules. - third_party/dawn/BUILD.bazel, the contents of which were copied from //third_party/BUILD.bazel and modified largely via find-and-replace to point to files relative to //third_party/externals/dawn. One exception is the cpu_wasm config_setting because @dawn isn't able to see Skia's //bazel/macros.bzl. - All other files Change-Id: Ib2d7bc972ef00b6b68370ce5c2839ffb70ed9a2f Bug: skia:12541, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538638 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-05-16 12:59:45 +00:00
new_local_repository(
name = "vulkan_headers",
[bazel] Move third party BUILD.bazel files to bazel/external See also http://cl/449188526 Change-Id: Idb775cd955c82f16c79a61bb3d417c2c92f88a88 Bug: skia:12541, skia:13323 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541217 Reviewed-by: Ravi Mistry <rmistry@google.com>
2022-05-17 11:47:44 +00:00
build_file = "bazel/external/vulkan_headers/BUILD.bazel",
[bazel] Move Dawn BUILD.bazel to third_party/bazel Rather than having a monolithic third_party/BUILD.bazel, this moves our Dawn rules to their own subdirectory and makes it callable via @dawn instead of //third_party/dawn. This will help with the G3 roll and make our rules more organized in general. This also rolls Dawn Roll Dawn from ab9757036bd6 to e831fb61046b (22 revisions) https://dawn.googlesource.com/dawn.git/+log/ab9757036bd6..e831fb61046b Suggested Review Order: - WORKSPACE.bazel, where we define @dawn and its deps (@vulkan_headers and @vulkan_tools). I initially thought I needed to define all of Dawn's deps in the workspace_file_content for new_local_repository, but that WORKSPACE file is ignored when building Skia rules. - third_party/dawn/BUILD.bazel, the contents of which were copied from //third_party/BUILD.bazel and modified largely via find-and-replace to point to files relative to //third_party/externals/dawn. One exception is the cpu_wasm config_setting because @dawn isn't able to see Skia's //bazel/macros.bzl. - All other files Change-Id: Ib2d7bc972ef00b6b68370ce5c2839ffb70ed9a2f Bug: skia:12541, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538638 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-05-16 12:59:45 +00:00
path = "third_party/externals/vulkan-headers",
workspace_file_content = "",
)
new_local_repository(
name = "vulkan_tools",
[bazel] Move third party BUILD.bazel files to bazel/external See also http://cl/449188526 Change-Id: Idb775cd955c82f16c79a61bb3d417c2c92f88a88 Bug: skia:12541, skia:13323 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541217 Reviewed-by: Ravi Mistry <rmistry@google.com>
2022-05-17 11:47:44 +00:00
build_file = "bazel/external/vulkan_tools/BUILD.bazel",
[bazel] Move Dawn BUILD.bazel to third_party/bazel Rather than having a monolithic third_party/BUILD.bazel, this moves our Dawn rules to their own subdirectory and makes it callable via @dawn instead of //third_party/dawn. This will help with the G3 roll and make our rules more organized in general. This also rolls Dawn Roll Dawn from ab9757036bd6 to e831fb61046b (22 revisions) https://dawn.googlesource.com/dawn.git/+log/ab9757036bd6..e831fb61046b Suggested Review Order: - WORKSPACE.bazel, where we define @dawn and its deps (@vulkan_headers and @vulkan_tools). I initially thought I needed to define all of Dawn's deps in the workspace_file_content for new_local_repository, but that WORKSPACE file is ignored when building Skia rules. - third_party/dawn/BUILD.bazel, the contents of which were copied from //third_party/BUILD.bazel and modified largely via find-and-replace to point to files relative to //third_party/externals/dawn. One exception is the cpu_wasm config_setting because @dawn isn't able to see Skia's //bazel/macros.bzl. - All other files Change-Id: Ib2d7bc972ef00b6b68370ce5c2839ffb70ed9a2f Bug: skia:12541, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538638 Reviewed-by: Ben Wagner <bungeman@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-05-16 12:59:45 +00:00
path = "third_party/externals/vulkan-tools",
workspace_file_content = "",
[bazel] Point to vk_mem_alloc from DEPS To make it easier to use the G3 version of this dep, we make a reference to it in the WORKSPACE.bazel, so we can refer to this external dep with the @ notation. I would like to do this for all of our third party deps, but one at a time. Change-Id: I03e0beca124225e0faf1232278dae641da8a3e4d Bug: skia:13240, skia:13211 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535358 Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-04-29 12:23:25 +00:00
)
[bazel] Move zlib and libpng out of //third_party/BUILD.bazel I had to copy some config_settings out of //bazel/common_config_settings because these are now treated as separate entities and cannot see that file. For libpng, note that we use a genrule to create the pnglibconf.h instead of pointing to one somewhere else. This ended up being easier than other things I tried. Another approach would be to not depend on the version in third_party/externals, but to clone it via new_git_repository [1] and apply a patch that creates the configuration file. [1] https://bazel.build/rules/lib/repo/git#new_git_repository Bug: skia:12541 Change-Id: I9a284775dc0f2bdabb145518d5f0803c74fb99fa Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545368 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-05-31 20:22:31 +00:00
new_local_repository(
name = "vulkanmemoryallocator",
build_file = "bazel/external/vulkanmemoryallocator/BUILD.bazel",
path = "third_party/externals/vulkanmemoryallocator",
workspace_file_content = "",
)
[bazel] Move remaining codec build rules to //bazel/external There are no functional changes to the rules, just a relocation. Change-Id: I90af5ec792fc54ce2978b0bbb1afd2c932e183b4 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545719 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-06-01 18:45:18 +00:00
new_local_repository(
name = "wuffs",
build_file = "bazel/external/wuffs/BUILD.bazel",
path = "third_party/externals/wuffs",
workspace_file_content = "",
)
[bazel] Move zlib and libpng out of //third_party/BUILD.bazel I had to copy some config_settings out of //bazel/common_config_settings because these are now treated as separate entities and cannot see that file. For libpng, note that we use a genrule to create the pnglibconf.h instead of pointing to one somewhere else. This ended up being easier than other things I tried. Another approach would be to not depend on the version in third_party/externals, but to clone it via new_git_repository [1] and apply a patch that creates the configuration file. [1] https://bazel.build/rules/lib/repo/git#new_git_repository Bug: skia:12541 Change-Id: I9a284775dc0f2bdabb145518d5f0803c74fb99fa Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545368 Reviewed-by: Ben Wagner <bungeman@google.com>
2022-05-31 20:22:31 +00:00
new_local_repository(
# Some other dependency downloads zlib but with their own rules
name = "zlib_skia",
build_file = "bazel/external/zlib/BUILD.bazel",
path = "third_party/externals/zlib",
workspace_file_content = "",
)
Reference in New Issue Copy Permalink