roll: pigweed pw_containers: Resolve pw_allocator co-dependencies in Android.bp
* Add pw_allocator as a dependency of pw_containers.
Many pw_containers libraries (e.g. pw_containers:deque) depend on
pw_allocator, but pw_containers was missing a dependency on
pw_allocator.
* Split out pw_containers_intrusive_lists from pw_containers.
As it was, that would introduce a dependency cycle:
pw_containers → pw_allocator → pw_containers → …
While other containers depend on pw_allocator, intrustive lists are a
*dependency of* pw_allocator. So adding this pw_containers ->
pw_allocator dependency would introduce a cycle between the two.
This splits out pw_containers_intrusive_lists into its own target
(group).
Then change pw_allocator to depend on pw_containers_intrusive_lists.
* Update pw_string to depend on pw_containers_headers.
Then there would be another dependency cycle:
pw_metric → pw_base64 → pw_string → pw_containers → pw_allocator
→ pw_metric → …
pw_string:string only depends on pw_containers:common and
pw_containers:iterator, so change that to pw_containers_headers which
does not depend on pw_allocator.
* Update pw_metric to depend on pw_containers_headers and
pw_containers_intrusive_lists.
Then there would be another dependency cycle:
pw_containers → pw_allocator → pw_metric → pw_containers → …
pw_metric uses only pw_containers:intrusive_list and
pw_containers:vector, so change that to pw_containers_headers and
pw_containers_intrusive_lists.
* Update pw_tokenizer to depend on pw_containers_headers.
Then there would be another dependency cycle:
pw_allocator → pw_metric → pw_tokenizer → pw_containers
→ pw_allocator → …
pw_tokenizer users only pw_containers:to_array, so change that to
pw_containers_headers.
Original-Bug: 523306525
Original-Reviewed-on: https://pigweed-review.googlesource.com/c/pigweed/pigweed/+/422132
Original-Revision: 4de0e92f5a52afa0205cf9f41ef14be1162cd420
Rolled-Repo: https://pigweed.googlesource.com/pigweed/pigweed
Rolled-Commits: 876420bfa4be76..4de0e92f5a52af
Roll-Count: 1
Roller-URL: https://cr-buildbucket.appspot.com/build/8679144952986931585
GitWatcher: ignore
CQ-Do-Not-Cancel-Tryjobs: true
Change-Id: Ib9492aca3433d1e0c118338880fcd9dbca43da00
Reviewed-on: https://pigweed-review.googlesource.com/c/pigweed/quickstart/bazel/+/422512
This repository contains a minimal example of a Bazel-based Pigweed project. It is a LED-blinking service (featuring RPC control!) for the Raspberry Pi Pico. It can also be run on any computer using the included simulator.
git clone https://pigweed.googlesource.com/pigweed/quickstart/bazel pw_bazel_quickstart cd pw_bazel_quickstart
The only dependency that must be installed is Bazelisk.
Bazelisk is a launcher for the Bazel build system that allows for easy management of multiple Bazel versions.
Instructions for installing Bazelisk can be found here.
To run the simulator, type: bazelisk run //apps/blinky:simulator_blinky Then, in a new console, connect to the simulator using: bazelisk run //apps/blinky:simulator_console
To start, connect a Raspberry Pi Pico, Pico 2, or debug probe via USB.
To run on the Raspberry Pi Pico, type: bazelisk run //apps/blinky:flash_rp2040 Then, in a new console, connect to the device using: bazelisk run //apps/blinky:rp2040_console
Once connected with a console, RPCs can be sent to control the LED. Try running:
device.set_led(True) device.set_led(False) device.toggle_led() device.blink(blink_count=3)
bazelisk test //... will run the unit tests defined in this project, such as the ones in modules/blinky/blinky_test.cc.
bazelisk run @pigweed//targets/rp2040/py:unit_test_server in one console followed by bazelisk test //... --config=rp2040 will also allow running the unit tests on-device.
Try poking around the codebase for inspiration about how Pigweed projects can be organized. Most of the relevant code in this quickstart (including RPC definitions) is inside modules/blinky, with some client-side Python code in tools/console.py.