skia2/bazel/Makefile

66 lines
3.5 KiB
Makefile
Raw Normal View History

generate:
echo "You do not need to run this any more for C++ code, only if you modify go code"
generate_go:
cd .. && bazelisk run //:gazelle -- update infra/bots/task_drivers modules/canvaskit/go
[bazel] Sketching out HelloWorld sk_app using GL bazel run //example:hello_world --config=clang causes a window to open and draws a circle and a square. Text to follow in a future CL. To make this work, I had to get rid of musl and use glibc. All the shared libraries (.so files) that were pre-built and available for download (e.g. from https://packages.debian.org/bullseye/amd64/libgl1/download) were compiled against glibc. When I tried to run a program statically linked with musl and dynamically linked against things using glibc, I got a segmentation fault on things like calloc(). Initial attempts to use glibc had failed because it was thought that the libc.so.6 file could only be referred to by absolute path (and thus Bazel would not be happy about it). As it turns out, that was simply a misconfiguration of the builtin_sysroot parameter to cc_common.create_cc_toolchain_config_info (see //toolchain/clang_toolchain_config.bzl). By setting that to `external/clang_linux_amd64` and not `external/clang_linux_amd64/usr`, the libc binary which had been extracted to `external/clang_linux_amd64/lib/x86_64-linux-gnu` was perfectly reachable from `external/clang_linux_amd64/usr/usr/lib/x86_64-linux-gnu/libc.so` To bring in the shared libraries to link against (e.g. X11, GL) I made build_toolchain.bzl easier to modify in that we simply need to add a debian download url and sha256 hash to a list (rather than having to plumb this through via arguments). Recommended Review Order: - example/BUILD.bazel (not sure if we always want to set bare link arguments like that or if we want to use "features" to pass those along to the toolchain). - tools/sk_app/BUILD.bazel to see initial cc_library for wrapping sk_app code. - toolchain/build_toolchain.bzl to see removal of musl and new list of debs. - toolchain/clang_toolchain_config.bzl (where use of the no-canonical-prefixes was key to compilation success). Notice also that we statically linked libc++ (I did not have any shared libraries for it locally, so I guessed a typical developer might not either). - Rest of toolchain/ for trivial renames. - bazel/Makefile to see extra docs on those targets and a new target that compiles all the exes so far for a quick way to test the build. - third_party/BUILD.bazel and src/gpu/BUILD.bazel which have non-generated changes. (all other BUILD.bazel files do). - go.mod, which needed to update the infra repo version in order to pick up http://review.skia.org/491736). Change-Id: I8687bd227353040eca2dffa9465798d8bd395027 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/492117 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-01-11 12:35:26 +00:00
# This target should be run after the go.mod file is updated (e.g. version rolls or new updates)
gazelle_update_repo:
cd .. && bazelisk run //:gazelle -- update-repos -from_file=go.mod -to_macro=go_repositories.bzl%go_repositories
# Run this target to test all known working Bazel builds
known_good_builds:
[bazel] Add "skia_internal" target that exposes private API for tests/tools. Organization v3.5, if we are keeping track :) This splits the "srcs" filegroup into "srcs" and "private_hdrs", and renames "hdrs" to "public_hdrs". To assist with the split, I created the macro split_srcs_and_hdrs. Rather than keep two separate lists of header and source files, I figured it would be easiest, at least for the common case, to keep one list of files and then have a for loop split them apart. I've tried to be consistent with having the list of files be named with a _FILES suffix - maybe we can use this as a marker to generate .gni files in the future? Suggested review order: - //bazel/macros.bzl. Note this needs a corresponding G3 change (http://cl/452279799) as well. The exports_files_legacy change is the better approach to something I manually handled yesterday when fixing the G3 roll. - //BUILD.bazel to see the new target skia_internal and the previous skia_core renamed to skia_public. - //src/core/BUILD.bazel to see a typical usage of split_srcs_and_hdrs. - //include/... to see the change to public_hdrs and private_hdrs - //src/... to see many more usages of split_srcs_and_hdrs - //tools/... to see changes to skia_internal where appropriate. - Everything else. Note that //modules/... might also need to be built with skia_internal instead of skia_public, but we can fix that up later, if necessary. Change-Id: Ie1cc969455d97b029b2d77faa222c4a9bad70671 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545716 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-06-01 18:45:46 +00:00
bazelisk build //:skia_public --config=clang_linux
bazelisk build //:skia_internal --config=clang_linux
[bazel] Add in hierarchical filegroup Bazel rules. The primary goal of this organization structure is to keep our top level BUILD.bazel file short, with as little logic as feasible. The logic required to control which files to include, which third_party deps are needed, what system libraries should be linked again, etc, should be in the BUILD.bazel file best should be as close to the affected files as feasible. In essence, we use filegroup() rules to bubble up the files needed to build Skia (all as one big cc_library call) and cc_library rules to bubble up the other components needed to build. For example, //src/ports/SkFontHost_FreeType.cpp needs FreeType, but only if we are compiling Skia with that type of font support. With the new organization structure in this CL, //src/ports/BUILD.bazel should have the logic that determines if the cpp file should be included in the build of Skia and if it is, that the Skia build should depend on //third_party:freetype2 Another example is //src/gpu/ganesh/BUILD.bazel, which chooses which of the dawn, gl, vulkan, etc backend sources, and the associated dependencies to include in the build. It does not specify what those are, but delegates to the BUILD.bazel files in the subdirectories housing the backend-specific code. The structure guidelines for BUILD.bazel files are as follows: - Have a filegroup() called "hdrs" (for public headers) or "srcs" (for private headers and all .cpp files) that is visible to the parent directory. This should list the files from the containing directory to include in the build. See //include/core/BUILD.bazel and //src/effects/BUILD.bazel as examples. - filegroup() rules can list a child directory's "hdrs" or "srcs" in their "srcs" attributes, but should not contain select statements pertaining to child directory files. See //include/gpu/BUILD.bazel and //src/gpu/ganesh/BUILD.bazel as examples. - May have a cc_library() called "deps". This can specify dependencies, cc_opts, and linkopts, but not srcs or hdrs. [1] See //src/codec/BUILD.bazel as an example. These should be visible to the parent directory. - "hdrs", "srcs", and "deps" for the primary Skia build (currently called "skia_core") should bubble up through //include/BUILD.bazel and //src/BUILD.bazel, one directory at a time. This CL demonstrates a very basic build of Skia with many features turned off (CPU only, no fonts, no codecs). Follow-on CLs will add to these rules as more targets are supported. See bazel/Makefile for the builds that work with just this CL. Suggested Review Order: - //BUILD.bazel to see the very small skia_core rule which delegates all the logic down stack. Note that it has a dependency on //bazel:defines_from_flags which will set all the defines listed there when compiling all the .cpp and .h files in skia_core *and* anything that depends on skia_core, but *not* //src:deps. - //include/BUILD.bazel and other BUILD.bazel files in the subdirectories of that folder. Note that the filegroups in //include/private/... are called "srcs" to be similar to how Bazel wants "private headers" to be in the "srcs" of cc_library, cc_binary, etc. and only public headers are to be in "hdrs" [2]. - //src/BUILD.bazel and other BUILD.bazel files in the subdirectories of that folder. //src/gpu/ganesh/... will be filled in for dawn, vulkan, and GL in the next CL. - //PRESUBMIT.py, which adds a check that runs buildifier [3] on modified BUILD.bazel files to make sure they stay consistently formatted. - //bazel/... to see the new option I added to make sksl opt-in or opt-out, so one could build Skia with sksl, but not with a gpu backend. - Misc .h and .cpp files, whose includes were removed if unnecessary or #ifdef'd out to make the minimal build work without GPU or SkSL includes. - //bazel/Makefile to see the builds that work with this CL. [1] Setting srcs or hdrs is error-prone at best, because those files will be compiled with a different set of defines than the rest of skia_core, because they wouldn't depend on //bazel:defines_from_flags. [2] https://bazel.build/reference/be/c-cpp#cc_library.hdrs [3] https://github.com/bazelbuild/buildtools/releases Change-Id: I5e0e3ae01ad42d672506d5aad1239f2512188191 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543977 Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Reviewed-by: Ben Wagner <bungeman@google.com>
2022-05-27 17:56:03 +00:00
bazelisk build //experimental/bazel_test/... --config=clang_linux
bazelisk run //experimental/bazel_test:bazel_test_exe --config=clang_linux
2022-05-27 18:47:29 +00:00
bazelisk build //example:hello_world_gl --config=clang_linux
bazelisk build //example:hello_world_vulkan --config=clang_linux
bazelisk build //example:hello_world_dawn --config=clang_linux
bazelisk build //example:vulkan_basic --config=clang_linux
bazelisk build //src/sksl/lex:sksllex --config=clang_linux
bazelisk build //tools/skdiff --config=clang_linux
bazelisk build //tools/skslc --config=clang_linux
bazelisk build //modules/canvaskit:canvaskit_wasm --config=ck_release
[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
rbe_known_good_builds:
[bazel] Add "skia_internal" target that exposes private API for tests/tools. Organization v3.5, if we are keeping track :) This splits the "srcs" filegroup into "srcs" and "private_hdrs", and renames "hdrs" to "public_hdrs". To assist with the split, I created the macro split_srcs_and_hdrs. Rather than keep two separate lists of header and source files, I figured it would be easiest, at least for the common case, to keep one list of files and then have a for loop split them apart. I've tried to be consistent with having the list of files be named with a _FILES suffix - maybe we can use this as a marker to generate .gni files in the future? Suggested review order: - //bazel/macros.bzl. Note this needs a corresponding G3 change (http://cl/452279799) as well. The exports_files_legacy change is the better approach to something I manually handled yesterday when fixing the G3 roll. - //BUILD.bazel to see the new target skia_internal and the previous skia_core renamed to skia_public. - //src/core/BUILD.bazel to see a typical usage of split_srcs_and_hdrs. - //include/... to see the change to public_hdrs and private_hdrs - //src/... to see many more usages of split_srcs_and_hdrs - //tools/... to see changes to skia_internal where appropriate. - Everything else. Note that //modules/... might also need to be built with skia_internal instead of skia_public, but we can fix that up later, if necessary. Change-Id: Ie1cc969455d97b029b2d77faa222c4a9bad70671 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545716 Reviewed-by: Ben Wagner <bungeman@google.com> Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2022-06-01 18:45:46 +00:00
bazelisk build //:skia_public --config=linux_rbe --remote_download_minimal
bazelisk build //:skia_internal --config=linux_rbe --remote_download_minimal
[bazel] Add in hierarchical filegroup Bazel rules. The primary goal of this organization structure is to keep our top level BUILD.bazel file short, with as little logic as feasible. The logic required to control which files to include, which third_party deps are needed, what system libraries should be linked again, etc, should be in the BUILD.bazel file best should be as close to the affected files as feasible. In essence, we use filegroup() rules to bubble up the files needed to build Skia (all as one big cc_library call) and cc_library rules to bubble up the other components needed to build. For example, //src/ports/SkFontHost_FreeType.cpp needs FreeType, but only if we are compiling Skia with that type of font support. With the new organization structure in this CL, //src/ports/BUILD.bazel should have the logic that determines if the cpp file should be included in the build of Skia and if it is, that the Skia build should depend on //third_party:freetype2 Another example is //src/gpu/ganesh/BUILD.bazel, which chooses which of the dawn, gl, vulkan, etc backend sources, and the associated dependencies to include in the build. It does not specify what those are, but delegates to the BUILD.bazel files in the subdirectories housing the backend-specific code. The structure guidelines for BUILD.bazel files are as follows: - Have a filegroup() called "hdrs" (for public headers) or "srcs" (for private headers and all .cpp files) that is visible to the parent directory. This should list the files from the containing directory to include in the build. See //include/core/BUILD.bazel and //src/effects/BUILD.bazel as examples. - filegroup() rules can list a child directory's "hdrs" or "srcs" in their "srcs" attributes, but should not contain select statements pertaining to child directory files. See //include/gpu/BUILD.bazel and //src/gpu/ganesh/BUILD.bazel as examples. - May have a cc_library() called "deps". This can specify dependencies, cc_opts, and linkopts, but not srcs or hdrs. [1] See //src/codec/BUILD.bazel as an example. These should be visible to the parent directory. - "hdrs", "srcs", and "deps" for the primary Skia build (currently called "skia_core") should bubble up through //include/BUILD.bazel and //src/BUILD.bazel, one directory at a time. This CL demonstrates a very basic build of Skia with many features turned off (CPU only, no fonts, no codecs). Follow-on CLs will add to these rules as more targets are supported. See bazel/Makefile for the builds that work with just this CL. Suggested Review Order: - //BUILD.bazel to see the very small skia_core rule which delegates all the logic down stack. Note that it has a dependency on //bazel:defines_from_flags which will set all the defines listed there when compiling all the .cpp and .h files in skia_core *and* anything that depends on skia_core, but *not* //src:deps. - //include/BUILD.bazel and other BUILD.bazel files in the subdirectories of that folder. Note that the filegroups in //include/private/... are called "srcs" to be similar to how Bazel wants "private headers" to be in the "srcs" of cc_library, cc_binary, etc. and only public headers are to be in "hdrs" [2]. - //src/BUILD.bazel and other BUILD.bazel files in the subdirectories of that folder. //src/gpu/ganesh/... will be filled in for dawn, vulkan, and GL in the next CL. - //PRESUBMIT.py, which adds a check that runs buildifier [3] on modified BUILD.bazel files to make sure they stay consistently formatted. - //bazel/... to see the new option I added to make sksl opt-in or opt-out, so one could build Skia with sksl, but not with a gpu backend. - Misc .h and .cpp files, whose includes were removed if unnecessary or #ifdef'd out to make the minimal build work without GPU or SkSL includes. - //bazel/Makefile to see the builds that work with this CL. [1] Setting srcs or hdrs is error-prone at best, because those files will be compiled with a different set of defines than the rest of skia_core, because they wouldn't depend on //bazel:defines_from_flags. [2] https://bazel.build/reference/be/c-cpp#cc_library.hdrs [3] https://github.com/bazelbuild/buildtools/releases Change-Id: I5e0e3ae01ad42d672506d5aad1239f2512188191 Bug: skia:12541 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543977 Reviewed-by: Leandro Lovisolo <lovisolo@google.com> Reviewed-by: Ben Wagner <bungeman@google.com>
2022-05-27 17:56:03 +00:00
bazelisk build //experimental/bazel_test/... --config=linux_rbe --remote_download_minimal
bazelisk run //experimental/bazel_test:bazel_test_exe --config=linux_rbe --remote_download_toplevel
2022-05-27 18:47:29 +00:00
bazelisk build //example:hello_world_gl --config=linux_rbe --remote_download_minimal
bazelisk build //example:hello_world_vulkan --config=linux_rbe --remote_download_minimal
bazelisk build //example:hello_world_dawn --config=linux_rbe --remote_download_minimal
bazelisk build //example:vulkan_basic --config=linux_rbe --remote_download_minimal
bazelisk build //src/sksl/lex:sksllex --config=linux_rbe --remote_download_minimal
bazelisk build //tools/skdiff --config=linux_rbe --remote_download_minimal
bazelisk build //tools/skslc --config=linux_rbe --remote_download_minimal
## TODO(kjlubick) CanvasKit in release mode (i.e. with Closure) requires
## https://github.com/emscripten-core/emscripten/pull/16640 to land
bazelisk build //modules/canvaskit:canvaskit_wasm --compilation_mode dbg --config=linux_rbe \
--remote_download_minimal
[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
iwyu_rbe:
bazelisk build //:skia_public --config=linux_rbe --config=enforce_iwyu \
--keep_going --remote_download_minimal
bazelisk build //example:hello_world_gl --config=linux_rbe --config=enforce_iwyu \
--keep_going --remote_download_minimal
bazelisk build //example:hello_world_vulkan --config=linux_rbe --config=enforce_iwyu \
--keep_going --remote_download_minimal
bazelisk build //example:hello_world_dawn --config=linux_rbe --config=enforce_iwyu \
--keep_going --remote_download_minimal
bazelisk build //example:vulkan_basic --config=linux_rbe --config=enforce_iwyu \
--keep_going --remote_download_minimal
iwyu:
bazelisk build //:skia_public --config=clang_linux --config=enforce_iwyu \
--keep_going
bazelisk build //example:hello_world_gl --config=clang_linux --config=enforce_iwyu \
--keep_going
bazelisk build //example:hello_world_vulkan --config=clang_linux --config=enforce_iwyu \
--keep_going
bazelisk build //example:hello_world_dawn --config=clang_linux --config=enforce_iwyu \
--keep_going
bazelisk build //example:vulkan_basic --config=clang_linux --config=enforce_iwyu \
--keep_going