Needed to fix the Dawn and Harfbuzz Bazel rules.
Change-Id: I21f63c970bdc972b97e42ef85d82d7f478bd45e2
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545721
Reviewed-by: Eric Boren <borenet@google.com>
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>
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>
This adds targets which test our Dawn, GL, and Vulkan backends.
It follows the hierarchical filegroup pattern, as
outlined in https://skia-review.googlesource.com/c/skia/+/543977
Suggested Review order:
- tools/sk_app/BUILD.bazel. For many things in tools, I anticipate
they will depend on //:skia_core and other //tools targets.
sk_app shows this off, as well how to make the target
specific to a given platform and pull in the proper native code.
I'm trying out setting test_only = True, to see if we can
partition Skia's tests and helpers from the actual Skia library.
- other changes to //tools/, especially looking at sk_app's
dependencies.
- //example/BUILD.bazel. This uses the cc_binary_with_flags which
existed previously [1] to make it so people don't have to
specify all the flags for a given binary and can build it as is.
These targets nows how up in //bazel/Makefile
- //include/... and //src/..., where some typos from previous
CLs were fixed and rules expanded.
- Misc changes to .cpp files to remove unnecessary includes
that were assuming the GL backend was being compiled in.
- All other changes
[1] 162dfca340/bazel/cc_binary_with_flags.bzl
Change-Id: Ieacec464d44368cad0da0890c7dc85a6c0b900c9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544317
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
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>
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>
Change-Id: Iac6b8a0b74fe23959f5ee814f4a30a5458ccf21e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/539936
Reviewed-by: John Stiles <johnstiles@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Change-Id: I2a1fedbbaabd57e4546c2a628f6d297e11f4244b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/539318
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
https://dawn.googlesource.com/dawn.git/+log/9483b741a884..be0abb611aed
$ git log 9483b741a..be0abb611 --date=short --no-merges --format='%ad %ae %s'
2022-05-09 dawn-autoroll Roll ANGLE from e316203a6a2f to 78d88796b44b (1 revision)
2022-05-08 dawn-autoroll Roll ANGLE from 225d8f83af71 to e316203a6a2f (1 revision)
2022-05-07 dawn-autoroll Roll SwiftShader from 00efa1913863 to 1dd93361b1d9 (1 revision)
2022-05-07 dawn-autoroll Roll ANGLE from cadb933fdb12 to 225d8f83af71 (2 revisions)
2022-05-07 dawn-autoroll Roll vulkan-deps from e13072c54977 to 626b2fd72bde (2 revisions)
2022-05-07 dawn-autoroll Roll SwiftShader from 74e34ab97aeb to 00efa1913863 (2 revisions)
2022-05-06 dawn-autoroll Roll ANGLE from 1d5d09e4191a to cadb933fdb12 (14 revisions)
2022-05-06 dawn-autoroll Roll vulkan-deps from 4957ae734445 to e13072c54977 (21 revisions)
2022-05-06 dawn-autoroll Roll SwiftShader from 62c1af08ea4d to 74e34ab97aeb (5 revisions)
2022-05-06 bclayton tint: Rename and move builtin_table and builtin-gen
2022-05-06 bclayton dawn: Fix clang warning treated as error
2022-05-06 zhaoming.jiang dawn: Add shader module validation for WGSL extension
2022-05-06 dawn-autoroll Roll ANGLE from 2ce60b52a239 to 1d5d09e4191a (10 revisions)
2022-05-05 jrprice Surface Vulkan validation messages in errors
2022-05-05 bclayton tint: Change all ProgramBuilder literals to 'i' or 'u' suffix
2022-05-05 dawn-autoroll Roll ANGLE from 9865ed8b8117 to 2ce60b52a239 (4 revisions)
2022-05-05 bclayton tint: Castable - support non-default-constructable return types
2022-05-05 dawn-autoroll Roll SwiftShader from 2e793ae08002 to 62c1af08ea4d (1 revision)
2022-05-05 amaiorano tint: add --overrides flag to specify pipeline overrides
2022-05-05 pkasting Fixes for C++20 support.
2022-05-05 bclayton tint: Add Bitcast helper
2022-05-05 bclayton tint: Fix CFI error in BlockAllocator
2022-05-05 dawn-autoroll Roll ANGLE from 9053a641bf5d to 9865ed8b8117 (1 revision)
2022-05-04 senorblanco OpenGLES: disable some end2end tests which require reading from depth textures.
2022-05-04 bclayton tint/reader/spirv: Generate 'i' suffixed literals
2022-05-04 bclayton tint: Merge [S|U]intLiteralExpression
2022-05-04 dawn-autoroll Roll SwiftShader from 643179694ec7 to 2e793ae08002 (1 revision)
2022-05-04 bclayton tint: Lex three types of integer literal
2022-05-04 dsinclair Enable more `gn check` results.
2022-05-04 dawn-autoroll Roll ANGLE from 84e42c3b04da to 9053a641bf5d (12 revisions)
2022-05-04 bclayton webgpu-cts/expectations.txt: Remove expectations that now pass
2022-05-04 amaiorano Disable angle dependency on wayland
2022-05-04 bclayton tint: Chromium-style fixes
2022-05-04 jamessliu2020 AST fuzzer: Change unary expression operator
2022-05-04 dawn-autoroll Roll SwiftShader from c75846ead9a0 to 643179694ec7 (3 revisions)
Created with:
roll-dep third_party/externals/dawn
Change-Id: I6656ab41573ce465e9ced94ad65731be9bc5dafe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538716
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Commit-Queue: Leandro Lovisolo <lovisolo@google.com>
G3 prefers license() first.
This was done mechanically with a big find/replace
Change-Id: I8c33c7bc10a6bec42e966cad81c259954e841811
Bug: skia:13211
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535898
Reviewed-by: Ben Wagner <bungeman@google.com>
Ran the following commands:
find -name "BUILD.bazel" -exec sed -i -e '1iload("//bazel:macros.bzl", "cc_library", "exports_files_legacy")\nexports_files_legacy()' {} +
buildifier --lint=fix --mode=fix -r .
This had the effect of making sure we can export all of our
files in G3 (until we no longer have legacy targets) and
making all of our cc_libraries shim-able.
bazel/macros.bzl has the human-contributed changes, the rest
were mechanical.
Change-Id: I8e24e30e74b038cfd072cdbe4078bfd1d213dd46
Bug: skia:13211
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535359
Reviewed-by: Ben Wagner <bungeman@google.com>
Change-Id: Ic93f264fb556ecf271f9c2642f7c60665669b092
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534499
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
It's time to better organize //third_party/BUILD.bazel
This CL starts by moving the "third party" stuff we closely own.
Change-Id: I3e0be0044b790794e94f34af6202860ce0a7b7aa
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531999
Reviewed-by: Ben Wagner <bungeman@google.com>
Change-Id: Ia4dac275a8614d7597e5c17cae77ad3770ba27e2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/532001
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
For importing into G3, this will simplify the regex needed
and allow us to stub out things not supported (e.g. gazelle)
Change-Id: I770f5dee6f29e555356742dae36212ad6cfb713a
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529836
Reviewed-by: Ben Wagner <bungeman@google.com>
This ports the GN skia_executable [1] and adds third_party
Bazel rules for spirv_cross, translated from [2]. spirv_cross,
unlike spirv_tools, did not have pre-made Bazel rules.
This binary compiles and links with
bazelisk build //tools/skslc --config=clang
[1] ad324a31e6/BUILD.gn (L712)
[2] ad324a31e6/third_party/spirv-cross/BUILD.gn (L10)
Change-Id: I4abd51889552153fc7e64a5f7f3d9f0f597524e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528044
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Includes a manual roll of Dawn, as well as tweaks to the Tint build
overrides.
Dawn needs git in order to generate a header that has the
version of Dawn compiled in. If we use Dawn's GN rules to
build it, we need git to generate that file.
Our (now updated) Bazel rules to build Dawn do not need to
do this because we (Skia) do not use this file [1]
[1] https://dawn.googlesource.com/dawn/+/088a600b03679cd20991f145173a573ed9c03480/src/dawn/common/BUILD.gn#177
Change-Id: Id19fdbb9b53fdad2397a0044a4a314b1444faeb0
Cq-Include-Trybots: luci.skia.skia.primary:Build-Debian10-Clang-x86_64-Debug-Dawn,Build-Win-Clang-x86_64-Release-Dawn
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528157
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
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>
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] ee69aa00ee
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>
Most of these are pretty mechanical generated changes.
IWYU noticed one issue with DSLCore.h, which was fixed here.
Change-Id: I5629565ad3c2817daa71907c62f932d93f9d78ab
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524617
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
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>
This regenerates the files and fixes the harfbuzz rule so CanvasKit
compiles.
Change-Id: I2db2bddaabf793f360e8a4fa1a6a2b96222dfdf8
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/522816
Reviewed-by: Ben Wagner <bungeman@google.com>
PS1 regenerates BUILD.bazel files
I suggest reviewing the deltas between PS1 and the latest
PS to focus on the interesting bits.
The changes here allow for a Vulkan-only build of HelloWorld
based on sk_app. The toughest change was properly fetching
the VisualID after removing the gl calls that used to
fill that in.
There are a few changes that fix resolution of Dawn
header files, but those won't actually be built until
a follow-on CL.
Change-Id: I54fb58b5dd7ecd4313562aed401759b3eaed53c0
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516999
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
PS 1 is re-generating existing BUILD.bazel files
PS 2 is generating BUILD.bazel files for tests/gms
PS 3+ makes modifications to build all of the gms and tests.
It is recommended to view this CL with just a diff between
PS 2 and the end, due to the large amount of generated changes
in PS 1 and 2.
We make a filegroup for the gms and tests because they need
to be compiled as one large blob in order for the registries
to work. Maybe in the future we will break these up, but at least
for WASM/JS, the overhead of starting a browser for each new
test would likely grind things to a halt, so we just group them
all together for now. It's also the most similar to what we
currently do.
In gm/BUILD.bazel and tests/BUILD.bazel, we add a cc_library
that encapsulates all of the deps of the tests, so we can
easily include that the build. These were discovered via
trial and error, not anything automatic or systematic.
The is_skia_dev_build config_setting is very similar to the
GN equivalent from which it was based.
The list of gms and tests to skip (e.g. which are incompatible
with WASM) was determined by building the wasm bundle:
modules/canvaskit$ make bazel_gms_release
tools/run-wasm-gm-tests$ make run_local_debug
# Don't forget to click the button on the screen after the
# browser loads
This way of invoking the tests will be replace soon with
`bazel test <something>`. As such, I didn't bother fully
documenting the current way.
Suggested review order:
- modules/canvaskit/BUILD.bazel taking note that we always
use profiling-funcs to make the stacktraces human readable.
- gm/BUILD.bazel and tests/BUILD.bazel to see the lists of
gms/tests. Notice the tests are roughly partitioned because
we don't support things like vulkan/PDF in the wasm build
and we will want a way to not build certain tests for
certain configurations
- tools/* noting some of the cc_libraries added to make
dependencies easier to add when needed.
- All other files.
Change-Id: I43059cd93c28af1c4c12b93d6ebd9c46a12d381f
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/506256
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
See toolchain/clang_toolchain_config.bzl for the c++17 switch.
Most of the other changes were automatically generated
(with the exception of //third_party).
Change-Id: I8c0f4b29b5967da3f48b17eb298a7e92156277ac
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/502407
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
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>
- Use latest emscripten toolchain (3.1.0)
- Autogenerate the atoms and manually fix some of the file lists.
- Add a known_good_builds target to bazel/Makefile to help
check the things we expect to work with Bazel.
Change-Id: Ia5f51e7b9eb5c108386820ad59180c8f862f5a70
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/491438
Reviewed-by: Ben Wagner <bungeman@google.com>
As a follow-up to https://skia-review.googlesource.com/c/skia/+/476219,
this sketches out how we can maybe use cc_library for the things
in //modules to make sure something in //src doesn't depend on
anything in //modules, for example.
The following succeeds:
bazel build //modules/skparagraph:skparagraph --config=clang \
--shaper_backend=harfbuzz_shaper --with_icu
As does `make bazel_canvaskit_debug` in //modules/canvaskit
Suggested Review Order:
- third_party/BUILD.bazel for ICU and harfbuzz rules. Pay
special attention to the genrules used to call the python
script for turning the icu .dat file into .S or .cpp.
- bazelrc and bazel/ for new flags and defines that control
use of ICU and harfbuzz. Unlike GN, with the public_defines
that get added in automatically if icu or harfbuzz is
depended upon, we need to set the defines at the top level.
This necessity might go away if we change the atoms to
depend on //modules/skshaper, which could define that flag.
- Top level BUILD.bazel files in //modules/skparagraph,
//modules/skshaper, //modules/skunicode, //modules/canvaskit
- All other .bazel file changes are automatic.
Bug: skia:12541
Change-Id: I38a9e0a9261d7e142eeb271c2ddb23f362f91473
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/478116
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
To make the atomic rules a bit easier to work with, in many
of the folders, this adds in cc_library rules to group
together the sources from that folder (and subfolders
where prudent). We only needs sources because those atoms
should have their headers as deps.
One issue that was pointed out is that there is currently
no way to restrict the inclusion of certain packages,
a la, `gn check`. For example, there is no mechanism from
stopping a dev from adding
#include "modules/canvaskit/WasmCommon.h"
to something in //src/core (except circular dependencies).
We can probably address that using Bazel's visibility
rules as needed:
https://docs.bazel.build/versions/main/visibility.htmlhttps://docs.bazel.build/versions/main/be/functions.html#package_group
It is recommended to look at this CL patchset by patchset.
PS1: Update gazelle command to generate rules in more folders.
PS2: A few changes to make generation work better.
PS3: The result of running make generate in //bazel
PS4: Adding the rules to build sksllex, the simplest binary I
could find in the Skia repo.
PS5: Adding the rules to build skdiff, a more complex binary.
I tried a few approaches, but ended up gravitating back
towards the layout where we have each folder/package
group up the sources. I imagine at some point, we'll have
skdiff depend on skia_core or something, which will
have things like //src/core, //src/codecs, //src/pathops
all bundled together.
PS7: Added in the groupings of sources, similar to what we had
earlier. I liked these for readability. These helped fix
up the //:skia_core build, and by extension, the CanvasKit
build.
Change-Id: I3faa7c4e821c876b243617aacf0246efa524cbde
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/476219
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
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>
This ports the third_party BUILD.gn files related to codecs
(with a best-effort on arm/SIMD stuff). This includes:
- libpng
- libjpeg-turbo
- libwebp
- wuffs (gif)
- libgifcodec
- dng_sdk and piex (raw codec)
This expands the string_flag_with_values macro to allow
multiple values to be set at once. This was added in Bazel 5.0.0,
however the latest pre-release version of that has a bug [1]
which slows down compilation dramatically. This was fixed at
ToT, but not released. As a result, I started using the Bazel
6 pre-release (via bazelisk).
The macro select_multi makes writing select() where multiple
elements could be on possible/easier.
One can try compiling certain codecs by running:
bazel build :skia-core --config clang --include_codec=raw_codec --include_codec=png_codec
Suggested Review Order:
- bazel/macros.bzl
- bazel/common_config_settings/defs.bzl and its BUILD.bazel
to see how the codec options are defined.
- BUILD.bazel to see how the codec settings are used.
- src/codec/BUILD.bazel to see the inclusion of Skia files to
deal with specific codecs.
- third_party/BUILD.bazel (while referencing the corresponding
BUILD.gn files, such as third_party/libwebp/BUILD.gn)
- Everything else.
Change-Id: I797375a35fa345d9835e7b2a2ab23371c45953c3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469456
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
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>
This makes use of Bazel's pre-defined platforms
https://github.com/bazelbuild/platforms
and some of our own defined values (see
//bazel/common_config_settings/BUILD.bazel) to customize
the build rules.
I verified this by building bazel_test locally for
linux x64 as well as using the third_party deps for
a WASM build (using build files not seen in this CL).
Suggested Review Order:
- https://docs.bazel.build/versions/main/platforms.html if not
already familiar with Bazel Platforms
- third_party/BUILD.bazel to see that 1) all globs have
been removed and 2) select() targets various
platform constants or groups of constants to control
sources, headers, and local_defines.
- common_config_settings/ to see the groups of constraints
created, as well as new constraint_settings defined
(skdebug_impl)
- supported_combinations/ to see how we can define supported
sets of the constraint values (aka Bazel platforms).
I imagine expanding this more, so we might have platforms
named "linux_x64_emptyfontmgr_vulkan" or such.
- //BUILD.bazel and bazel_test.cpp to see use of SkDebugf.
- Everything else.
Change-Id: I49e4abdbcf7b76f0674efdbb1f53dc8823d110ee
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/463517
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Owners-Override: Kevin Lubick <kjlubick@google.com>
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>
