This moves the Build-Debian10-BazelClang-x86_64-Release-IWYU
job from experimental to on when a file in one of the
folders that we enforce IWYU is modified (currently
for svg, sksl, and now, debugger).
Change-Id: Ia6fe1e7b30fc486db3eb081b6a64bc4c250cbf0b
Bug: skia:13052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/525796
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Kevin Lubick <kjlubick@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>
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 the Bazel files. Use it as the base change when
comparing patchsets.
IWYU seems to do a good job of working with MyFile.cpp and
MyFile.h, but if there is just a MyHeader.h, it doesn't always
seem to throw errors if the includes aren't correct. This was
observed with include/sksl/DSL.h This might be due to the fact
that headers are not compiled on their own, so they are never
sent directly to the IWYU binary.
This change sets enforce_iwyu_on_package() on the all sksl
packages and then fixes the includes until all those checks
are happy. There were a few files that needed fixes outside
of the sksl folder. Examples include:
- src/gpu/effects/GrConvexPolyEffect.cpp
- tests/SkSLDSLTest.cpp
To really enforce this, we need to add a CI/CQ job that runs
bazel build //example:hello_world_gl --config=clang \
--sandbox_base=/dev/shm --features skia_enforce_iwyu
If that failed, a dev could make the changes described in
the logs and/or run the command locally to see those
prescribed fixes.
I had to add several entries to toolchain/IWYU_mapping.imp
in order to fix some private includes and other atypical
choices. I tried adding a rule there to allow inclusion of
SkTypes.h to make sure defines like SK_SUPPORT_GPU, but
could not get it to work for all cases, so I deferred to
using the IWYU pragma: keep (e.g. SkSLPipelineStageCodeGenerator.h)
Change-Id: I4c3e536d8e69ff7ff2d26fe61a525a6c2e80db06
Bug: skia:13052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/522256
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
This will use the recently added Bazel toolchain feature
to enforce proper includes for all files in //src/svg/...
In the future, I envision a CI/CQ job that will run
bazel build with a few different configurations and the
--feature skia_enforce_iwyu on to make sure we don't
regress.
Change-Id: Ibb9f816ab626415c11bd2b9b74c503297c4b0723
Bug: skia:13052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/521036
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
PS1 regenerates the Bazel files.
It is recommended to review this CL with a diff from PS1.
Example output when a file does not pass the test:
tools/sk_app/CommandSet.h should add these lines:
#include "include/core/SkTypes.h"
#include "include/private/SkTArray.h"
#include "tools/skui/InputState.h"
#include "tools/skui/Key.h"
#include "tools/skui/ModifierKey.h"
namespace sk_app { class Window; }
tools/sk_app/CommandSet.h should remove these lines:
- #include "tools/sk_app/Window.h"
The full include-list for tools/sk_app/CommandSet.h:
#include "include/core/SkString.h"
#include "include/core/SkTypes.h"
#include "include/private/SkTArray.h"
#include "tools/skui/InputState.h"
#include "tools/skui/Key.h"
#include "tools/skui/ModifierKey.h"
#include <functional>
#include <vector>
class SkCanvas;
namespace sk_app { class Window; }
---
This makes use of Bazel's toolchain features
https://bazel.build/docs/cc-toolchain-config-reference#features
to allow us to configure compiler flags when compiling
individual files. This analysis is off by default, and can
be turned on with --features skia_enforce_iwyu. When enabled,
it will only be run for files that have opted in.
Example:
bazelisk build //example:hello_world_gl --config=clang \
--sandbox_base=/dev/shm --features skia_enforce_iwyu
There are two ways to opt files in:
- Add enforce_iwyu = True to a generated_cc_atom rule
- Add enforce_iwyu_on_package() to a BUILD.bazel file
(which enforces IWYU for all rules in that file)
Note that Bazel does not propagate features to dependencies
or dependents, so trying to enable the feature on cc_library
or cc_executable targets will only impact any files listed in
srcs or hdrs, not deps. This may be counter-intuitive when
compared to things like defines.
IWYU supports a mapping file, which we supply to help properly
handle things system headers (//toolchain/IWYU_mapping.imp)
Suggested Review Order:
- toolchain/build_toolchain.bzl to see how we get the IWYU
binaries into the toolchain
- toolchain/BUILD.bazel and toolchain/IWYU_mapping.imp
to see how the mapping file is made available for
all compile steps
- toolchain/clang_toolchain_config.bzl, where we define the
skia_enforce_iwyu feature to turn on any verification at
all and skia_opt_file_into_iwyu to enable the check for
specific files using a define.
- toolchain/clang_trampoline.sh, which is the toolchain is
configured to call instead of clang directly (see line 83
of clang_toolchain_config.bzl). This bash script used to
just forward all arguments directly onto clang. Now it
inspects them and either calls clang directly (if
it does not find the define in the arguments or we are
linking [bazel sometimes links with clang instead of ld])
or calls clang and then include-what-you-use. In all cases,
the trampoline sends the arguments to clang and IWYU
unchanged).
- //tools/sk_app/... to see enforcement enabled (and fixed)
for select files, as an example of that method.
- //experimental/bazel_test/... to see enforcement enabled
for all rules in a BUILD.bazel file.
- all other files.
Change-Id: I60a2ea9d5dc9955b6a8f166bd449de9e2b81a233
Bug: skia:13052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/519776
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Commit-Queue: Kevin Lubick <kjlubick@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>
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>
In order to extract the PNG files produced by our CanvasKit gms,
we need our JS tests to POST them to a server which can write to
disk. The easiest way to do this is to use the test_on_env
rule defined in the Skia Infra repo for exactly this purpose.
This required https://skia-review.googlesource.com/c/buildbot/+/510717
to be able to configure the binary correctly and
https://skia-review.googlesource.com/c/buildbot/+/511862, for nicer
debugging so the skia-infra dep was updated via the following commands:
$ go get go.skia.org/infra@d8a552a29e
$ go mod download
$ make -C infra/bots train
$ make -C bazel gazelle_update_repo
This caused many automated changes to infra/bots/tasks.json
The flow is:
1. User types bazelisk test :hello_world_test_with_env
2. The test_on_env rule starts gold_test_env and waits
for the file defined in $ENV_READY_FILE to be created.
3. gold_test_env starts a web server on a random port. It
writes this port number to $ENV_DIR/port. Then, it
creates $ENV_READY_FILE to signal ready.
4. test_on_env sees the ready file and then starts the
karma_test rule. (Reminder: this is a bash script
which starts karma using the Bazel-bundled chromium).
5. The karma_test rule runs the karma.bazel.js file (which
has been injected with some JS code to fill in Bazel
paths and settings) using Bazel-bundled node. This reads
in the port file and sets up a Karma proxy to redirect
/gold_rpc/report to http://localhost:PORT/report
6. The JS tests run via Karma (and do assertions via Jasmine).
Some tests, the gms, make POST requests to the proxy.
7. gold_test_env gets these POST requests writes the images
to a special Bazel folder on disk as defined by
$TEST_UNDECLARED_OUTPUTS_DIR.
8. test_on_env identifies that the tests finish (because the
karma_test script returns 0). It sends SIGINT to gold_test_env.
9. gold_test_env stops the webserver. The special Bazel folder
will zip up anything inside it and make it available for
future rules (e.g. a rule that will upload to Gold via goldctl).
Suggested Review Order:
- bazel/karma_test.bzl to see the test_on_env rule bundled into
the karma_test macro. I chose to put it there because it might
be confusing to have to define both a karma_test and test_on_env
rule in the same package but not be able to call one because it
will fail to talk to the server.
- gold_test_env.go to see how the appropriate files are written
to signal the environment is ready and the handlers are set up.
- karma.bazel.js to see how we make our own proxy given the
port from the env binary. The fact that we could not create
our own proxy with the existing karma_test rule was why the
chain ending in https://skia-review.googlesource.com/c/skia/+/508797
had to be abandoned.
- tests/*.js to see how the environment is probed via /healthz
and then used to make POST requests with data.
- Everything else.
Change-Id: I32a90def41796ca94cf187d640cfff8e262f85f6
BUG: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/510737
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
In order to load CanvasKit, we need to add support for statically
served files. On the karma side, this is done by adding an
object [1] to the files list (example: [2]).
Then, we need to include canvaskit.js in with the karma test
files and use the callback to load canvaskit.wasm from the
correct file location.
[1] http://karma-runner.github.io/6.3/config/files.html
[2] 4f7b656012/modules/canvaskit/karma.conf.js (L13)
Change-Id: I7482d6e949a5e8efd0ca882efe5afbe0dc16c0e4
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/510736
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
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] c33c7be17f/bazel/deps.bzl (L10)
[2] 700b7a3c5f/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>
PS1 regenerates the BUILD.bazel files
This allows us to use closure to minify the JS in canvaskit.js
Change-Id: Ib8326d2e3a19cd2168b740b6946f9165a2810133
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/509177
Reviewed-by: Ben Wagner <bungeman@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>
PS 1 adds particles to the build
PS 2+ ports many of the options from //modules/canvaskit/compile.sh
With this CL, all the CanvasKit tests pass with both the
debug and release build.
Change-Id: Id70f0c16a087109c56949417f940849f2e3b5200
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/504537
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
PS 1 regenerates existing Bazel files
PS 2 adds generated Bazel files to skottie and its dependencies,
as well as incorporating it into CanvasKit.
This changes the version of Bazel we use to 5.0.0 (recently
released).We had been using a pre-release of 6.0 because we
wanted the new features in one of the 5.0 release candidates,
but not the regression that was there (and reverted before the
full 5.0 release). I'd like to stick to the latest stable Bazel
release where possible.
Suggested Review Order:
- //modules/skottie/BUILD.bazel (this was hand written
to encapsulate the skottie library). The files in the
deps are based on skottie.gni.
- //modules/skresources/BUILD.bazel and //modules/sksg/BUILD.bazel
which expose all sources
- //third_party/file_map_for_bazel.json which ignores the
ffmpeg libraries (we won't actually build the SkVideoDecoder
stuff because HAVE_VIDEO_DECODER is not set).
- //modules/canvaskit/BUILD.bazel which makes use of the skottie
library and includes the interface skottie.js file.
- .bazelversion which changes the Bazel version used (e.g. by
Bazelisk).
- All other changes should be auto-generated or related to
deleted files.
Change-Id: Ic26f9a9dea5310f2cbd9cda7d701847924a39a22
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/503828
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
- 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>
This documents the various factory settings (I kept getting
confused as to what each was doing).
Additionally, this makes setting the factory flag bring in
the dependent code as well (like our current GN rules do).
Change-Id: I93437651b078baac04433c14c573a95982b7bc15
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/493396
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 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>
This uses the gazelle extension from
https://skia-review.googlesource.com/c/buildbot/+/473357
Review Tips:
- Ignore any changes to .h or .cpp files. Those have been
pulled out into their own CLs.
- Start with bazel/macros.bzl.
- Read the CL with the generation code, if you haven't already.
- Look at third_party/file_map_for_bazel.json.
- See experimental/bazel_test for an idea of how a cc_binary
would be made.
- Spot check one or two of the BUILD.bazel files.
This CL generates the "atomic" rules for src/, include/ and
modules/skshaper, as a starting point.
`bazel build --config clang //include/...` works
`bazel build --config clang //src/...` starts compiling,
(which verifies that the BUILD.bazel files are all valid),
but runs into errors because not all third_party deps have
been resolved, and there are some files missing from the
toolchain still (e.g. EGL headers).
Change-Id: Ib7e0fb0efdb9f08655f06cbc56e9bb4cf416294b
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/474240
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
This will hopefully let us pre-package certain binaries (e.g. DM,
fuzz) with more sensible defaults and not make the developer
type out all the settings.
For CanvasKit, which specifies its own build flags, I think I'll
need to make another transition setup, which would go in something
like modules/canvaskit/ck_binary_with_flags.bzl or something.
Some sausage-case-names were converted to snake_case_names as per
go/build-style#target-naming
The example this is based off is worth a look through before
diving into this:
https://github.com/bazelbuild/examples/tree/main/rules/starlark_configurations/cc_binary_selectable_copts
Change-Id: Ia919d47f4d1aa25cf294af7918e36d38838c179e
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472688
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Importantly, this adds options for encoding using
certain codecs, not just decoding.
Change-Id: I4a610ebf985b67d4545c71b3f3eed4c7807e6a26
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472277
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>
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>
