Lines Matching +full:windows +full:- +full:build +full:- +full:rules
1 .. _seed-0111:
4 0111: Make Bazel Pigweed's Primary Build System
8 :name: Make Bazel Pigweed's Primary Build System
10 :proposal_date: 2023-09-26
15 -------
17 -------
19 <https://bazel.build/>`_ as its primary build system, replacing `GN
22 Pigweed is and will continue to be a multi-build-system project. As modular
24 projects whatever their build system. To facilitate this, we provide BUILD
31 starting a new project using Pigweed from day one, you will ask: which build
32 system *should* I use? This is what we mean by Pigweed's *primary* build
35 Pigweed's primary build system has been GN, but soon will be Bazel.
37 ----------
39 ----------
40 GN has been Pigweed's primary build system since inception, and we've developed
41 an extensive GN build that was used to successfully ship products at scale. GN
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
52 rules: for C/C++, for Python, for Go (though those are deprecated). With
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
68 We would like Pigweed to recommend a build system that does not suffer from these
71 These limitations are not new. What's changed is the build system landscape.
73 emphasizing multi-target builds. But the alternatives have now matured.
75 --------
77 --------
78 The proposal is to make Bazel the recommended build system to use with Pigweed,
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
81 rules we wish to reuse, and when necessary to core Bazel.
87 management and remote build execution. We will make it easy for Pigweed
91 maintenance rather than new build features. No earlier than 2026, if no
99 -------
101 -------
102 This section lists the high-level milestones for Pigweed's Bazel support, and
110 recommendations about build system choice (embodied in docs and in what we tell
115 * **M0: Good for Most.** We can recommend Bazel as the build system for most
120 * Out of scope for M0: Windows support. We have to start somewhere, and we're
124 including ones that need Windows support. The target date is end of Q1
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
148 * Bazel proto codegen is feature-complete, `b/301328390
150 * Multiplatform build is ergonomic thanks to the adoption of
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>`_, …
156 * Clang sanitizers (asan, msan, tsan) are easy to enable in the Bazel build, `b/301487567
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
183 * We have a "build system support matrix" that compares the features
184 available in the three main build systems (Bazel, CMake, GN),
192 ------------
194 ------------
196 a different build system.
200 Pigweed does not have the resources to bring GN to parity with modern build
202 with another large project rather than build capabilities ourselves.
206 CMake is `the most popular build system for C++ projects
207 <https://www.jetbrains.com/lp/devecosystem-2021/cpp/#Which-project-models-or-build-systems-do-you-r…
209 it's not a viable candidate for Pigweed's primary build system:
211 * **No multi-toolchain builds** Unlike Bazel and GN, CMake does not support
212 multi-toolchain builds.
215 Python and Rust need first-class treatment.
219 support for Bazel is also well-developed <https://bazel.build/install/ide>`_.
221 Other build systems
223 There are other multi-lingual, correctness-emphasizing build systems out there,
225 <https://buck2.build/>`_. We did not consider them realistic targets for
227 existing Bazel build that's in use by some projects, as well as a closer
230 --------------
232 --------------
236 * `SEED-0113
237 <https://pigweed-review.googlesource.com/c/pigweed/pigweed/+/173453>`_:
239 * SEED-????: Pigweed CI/CQ for Bazel
241 ----------------------------
243 ----------------------------
244 This SEED has not focused on why Bazel is a great build system. This is because
245 we are not choosing Bazel over other major build systems, like Meson or Buck2,
246 for its specific features. We are motivated to recommend a new build system
247 because of GN's limitations, and we choose Bazel because we have a pre-existing
253 * **Correct incremental builds.** It's great to be able to trust the build
259 * **Remote build execution** Bazel has excellent native support for `executing
260 build actions in a distributed manner on workers in the cloud
261 <https://bazel.build/remote/rbe>`_. Although embedded builds are typically
262 small, build latency and infra test latency is a recurring concern among
265 * **Python environment management.** The Python rules for Bazel take care of
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.