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>
