Commit Graph

26 Commits

Author SHA1 Message Date
Kevin Lubick
62f57a02b3 [includes] Enforce IWYU on src/utils
Client changes:
 - cl/443664347
 - cl/444232853
 - http://ag/17915718
 - http://ag/17913178
 - https://crrev.com/c/3602239

Change-Id: I16bcdbbe2b13bbf52f007b0f131e9ee0c14ed237
Bug: skia:13052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/532257
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-04-28 17:32:20 +00:00
Jim Van Verth
42f710f3fa Reland "[graphite] Move Graphite into Skia base directories."
This is a reland of commit ae5e846047

Original change's description:
> [graphite] Move Graphite into Skia base directories.
>
> Change-Id: Ie0fb74f3766a8b33387c145bd1151344c25808cb
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528708
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Jim Van Verth <jvanverth@google.com>

Change-Id: Ia575fd49206ad0b665a6a9153317e738bb321446
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529059
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
2022-04-11 18:37:20 +00:00
Jim Van Verth
ab4d4ae9e2 Revert "[graphite] Move Graphite into Skia base directories."
This reverts commit ae5e846047.

Reason for revert: Breaking Google3

Original change's description:
> [graphite] Move Graphite into Skia base directories.
>
> Change-Id: Ie0fb74f3766a8b33387c145bd1151344c25808cb
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528708
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Jim Van Verth <jvanverth@google.com>

Change-Id: Ia57992a22c42b17216b40fd29452865f957fb802
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528653
Auto-Submit: Jim Van Verth <jvanverth@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
2022-04-09 01:02:26 +00:00
Jim Van Verth
ae5e846047 [graphite] Move Graphite into Skia base directories.
Change-Id: Ie0fb74f3766a8b33387c145bd1151344c25808cb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528708
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
2022-04-08 20:46:40 +00:00
Kevin Lubick
a9f6ceebed [bazel] Add executable for skslc
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>
2022-04-08 17:25:24 +00:00
Kevin Lubick
f0fdce0b42 [includes] Add pragma for SkTypes.h
IWYU doesn't always understand that we want defines to come from
certain files, so we add a pragma to force it.

This also adds an extra entry to known_good_builds so I don't miss
this type of thing again when building locally.

Change-Id: I2321ea95edfc6a4506d51a011983965eb9bdf1c0
Bug: skia:13052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528164
Reviewed-by: John Stiles <johnstiles@google.com>
Owners-Override: Kevin Lubick <kjlubick@google.com>
2022-04-07 13:04:14 +00:00
Kevin Lubick
3f335b6e01 [canvaskit] Can build debug mode with RBE
Release mode requires https://github.com/emscripten-core/emscripten/pull/16640
to land

Change-Id: I70295d4c2f884ebeb400bd30f4ef28d7695e48df
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/526047
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
2022-03-31 13:59:15 +00:00
Kevin Lubick
556ca8f7ee [includes] Enforce IWYU for //tools/debugger/...
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>
2022-03-30 13:53:13 +00:00
Kevin Lubick
fed97e8f40 [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-28 13:56:16 +00:00
Kevin Lubick
0364f7b80e [bazel] Fix/update rules
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>
2022-03-21 17:19:54 +00:00
Kevin Lubick
08ece0c9a0 [includes] Enforce IWYU on sksl code
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>
2022-03-21 12:43:02 +00:00
Kevin Lubick
9301fe3779 [bazel] Test enforcement of IWYU on SkSVG backend.
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>
2022-03-16 14:20:14 +00:00
Kevin Lubick
e253cc3e55 [bazel] Use toolchain features to opt files into being IWYU compliant.
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>
2022-03-16 13:09:46 +00:00
Kevin Lubick
7ac7413f08 [bazel] Support Vulkan
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>
2022-03-08 21:21:17 +00:00
Kevin Lubick
5fb37db69f [bazel] Use bazel to build task drivers
One very important, but agonizing to discover, change was
to go_repositories.bzl. Without it, we see cryptic errors like:
external/org_chromium_go_luci/cipd/api/cipd/v1/BUILD.bazel:22:17: no such package '@org_chromium_go_luci//go.chromium.org/luci/cipd/api/cipd/v1': BUILD file not found in directory 'go.chromium.org/luci/cipd/api/cipd/v1' of external repository @org_chromium_go_luci. Add a BUILD file to a directory to mark it as a package. and referenced by '@org_chromium_go_luci//cipd/api/cipd/v1:api_go_proto'

The rest of these changes are very similar to
https://skia-review.googlesource.com/c/buildbot/+/514074
which also has justification for the use of task drivers,
even in a Bazel-driven world.

All the BUILD.bazel files under infra/bots/task_drivers were
generated by Gazelle.

Note that the infra/bots/BUILD.bazel can happily build and
package up the task drivers from the infra repo. The old
build_task_drivers tasks did this too, because we have some
task drivers that are used in both repos.

Change-Id: I13c46c62bc7a6a4bfe7935b28efbfb34caabb6f2
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/515296
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
2022-03-03 16:12:18 +00:00
Kevin Lubick
acab911351 [bazel] Make use of test_on_env to spin up server for gms
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>
2022-02-28 14:05:54 +00:00
Kevin Lubick
9cb74e9079 [bazel] Compile gms for wasm and WebGL
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>
2022-02-09 18:56:17 +00:00
Kevin Lubick
a803794df7 [canvaskit] Add more features to Bazel build
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>
2022-02-04 21:33:20 +00:00
Kevin Lubick
e94b52c442 [canvaskit] Add skottie to Bazel build
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>
2022-02-04 19:18:27 +00:00
Kevin Lubick
6e63f4925e [bazel] Use font manager in HelloWorld.
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>
2022-01-11 16:22:52 +00:00
Kevin Lubick
7a14f783bd [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 13:06:19 +00:00
Kevin Lubick
048545d249 Set up basic hello world sk_app
Change-Id: I233e7653eadcce87067def841b2f28c700f96045
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/492096
Reviewed-by: Brian Salomon <bsalomon@google.com>
2022-01-06 20:29:35 +00:00
Kevin Lubick
96e4053be7 Update Bazel files
- 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>
2022-01-06 18:10:57 +00:00
Kevin Lubick
4bd08c52c0 [infra] Add SkParagraph (harfbuzz, ICU) to Canvaskit Bazel build.
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>
2021-11-30 21:01:06 +00:00
Kevin Lubick
6ba9f702ba [bazel] Try adding cc_binary rules that use generated rules
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.html
https://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>
2021-11-30 18:18:53 +00:00
Kevin Lubick
cc9d0cd5a9 [bazel] Add go/gazelle to WORKSPACE and use c++ extension.
This adds a simple go program to test the installed go
toolchain, and a Make rule to codify the arguments to
our gazelle binary, built with extensions.

I could not figure out how to get the .json file to work
with the gazelle() Bazel rule, but this works ok for now.

Bug: skia:12541
Change-Id: I5067b15c7518951aeb69559d3871799d3b5745f4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/475716
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
2021-11-23 20:00:15 +00:00