AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
59,641 Commits 1 Branch 0 Tags 544 MiB
4bd442901f
Commit Graph

4 Commits

Author SHA1 Message Date
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
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
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