Lines Matching +full:rust +full:- +full:embedded
1 .. _seed-0111:
10 :proposal_date: 2023-09-26
15 -------
17 -------
22 Pigweed is and will continue to be a multi-build-system project. As modular
23 middleware, Pigweed aspires to be easy to integrate with existing embedded
29 ergonomic way to start a new embedded project, as well as developer tooling
37 ----------
39 ----------
42 is fast and extensible, and its flexible toolchain abstraction is well-suited
43 to the multi-target builds that arise in most embedded projects.
47 #. **Small community.** GN is a niche build system: the only major open-source
49 major nonprofit or corporation. Few users or open-source contributors come
53 Rust entering Pigweed, we are now developing GN rules for Rust. There are
54 no built-in or community-provided rules we could adopt instead. Developing
55 all rules in-house gives us flexibility, but requires large up-front and
61 :ref:`module-pw_env_setup` and GN is blurred, making GN-built Pigweed as
73 emphasizing multi-target builds. But the alternatives have now matured.
75 --------
77 --------
79 and the best overall build system for embedded developers. This will involve a
80 combination of contributions to Pigweed itself, to existing open-source Bazel
99 -------
101 -------
102 This section lists the high-level milestones for Pigweed's Bazel support, and
127 * **M2: Best.** We develop compelling features for embedded within the
134 * **Configurable toolchains** exist for host and embedded, for C++ and Rust.
135 A separate upcoming SEED will cover this area in detail, but the high-level
137 for embedded targets. This is required for milestone M0, except for Windows
141 * **Core build patterns** (facades, multi-platform build, third-party crate
142 deps for Rust) are established, documented, and usable.
148 * Bazel proto codegen is feature-complete, `b/301328390
152 …ild/proposals/blob/main/designs/2023-06-08-standard-platform-transitions.md#depend-on-a-target-bui…
153 and `platform-based flags
154 …<https://github.com/bazelbuild/proposals/blob/main/designs/2023-06-08-platform-based-flags.md>`_, …
161 * On-device testing pattern for Bazel projects developed and documented, `b/301332139
167 interfaces to Pigweed developer tooling like :ref:`module-pw_console`,
168 :ref:`module-pw_cli`, etc.
170 * M0: GN-free bootstrap for Bazel-based projects is designed and prototyped, `b/274658181
176 * **Onboarding** for users new to Pigweed-on-Bazel is easy thanks to
192 ------------
194 ------------
207 <https://www.jetbrains.com/lp/devecosystem-2021/cpp/#Which-project-models-or-build-systems-do-you-r…
211 * **No multi-toolchain builds** Unlike Bazel and GN, CMake does not support
212 multi-toolchain builds.
213 * **No Python or Rust support** Again unlike Bazel and GN, CMake is primarily
215 Python and Rust need first-class treatment.
219 support for Bazel is also well-developed <https://bazel.build/install/ide>`_.
223 There are other multi-lingual, correctness-emphasizing build systems out there,
230 --------------
232 --------------
236 * `SEED-0113
237 <https://pigweed-review.googlesource.com/c/pigweed/pigweed/+/173453>`_:
239 * SEED-????: Pigweed CI/CQ for Bazel
241 ----------------------------
243 ----------------------------
247 because of GN's limitations, and we choose Bazel because we have a pre-existing
261 <https://bazel.build/remote/rbe>`_. Although embedded builds are typically
266 standing up a Python interpreter with a project-specific virtual
267 environment, a functionality we had to develop in-house for our GN build.
269 third-party rules for C++, Python, Java, Go, Rust, and other langauges.