1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
# Build/lint orchestration for rpi-kickstart. The default (AArch32) target
# and the linker-script rustflags are pinned in .cargo/config.toml, so
# plain `cargo` invocations pick them up without repeating flags here.
#
# AArch64 is named explicitly below rather than made a second default,
# because there is no way to ask cargo for two. Every recipe that builds
# anything therefore runs twice: this crate's source is architecture-
# neutral, but its examples link, and linking is where a load address or a
# missing `rpi-link.x` shows up.
#
# ARMv6 (Pi 1, Pi Zero) is deliberately absent. `rpi-hal` and
# `rpi-hal-embassy` both carry recipes for it, at the cost of a nightly
# toolchain and `-Z build-std` -- that target is tier 3 and rustup
# publishes no `core` for it. Nothing here is architecture-specific, so
# adding those recipes is a `make` change and not a source one, and it can
# wait for a board that wants it.
# Both architectures in one invocation. `--target` may be repeated, which
# is what keeps each recipe below to two lines instead of four -- the
# second dimension being the feature set, and that one cannot be folded
# away.
ARCHES :=
:
# Every module, plus one chip. Enumerated rather than `--all-features`,
# which is wrong here and not merely inelegant: the chip features forward
# to `rpi-hal`'s, and turning on more than one resolves by its
# `bcm2711` > `bcm2837` > `bcm2835` precedence instead of failing. A
# sweep would therefore check -- and link example images against -- a
# peripheral base nothing in this repository runs on.
#
# `bcm2837` is the one named because the examples are Pi 2/3 images. A
# board is free to select another; what this list covers is that the
# modules compile, and none of them is chip-conditional.
FEATURES :=
# The machine running the build. Tests run there, because that is the only
# place `cargo test` has to run them: the bare-metal targets have no test
# harness and nothing to execute one on.
HOST :=
# The modules whose tests are pure and so build for the host. Not
# $(FEATURES): most of those reach `rpi-hal`, which compiles only for a
# Pi, and a module that does cannot be tested this way at all.
#
# `splash-build` and `metrics-build` appear only here: they need `std`, and
# are meant to run on the host in a build script, which is exactly where
# this runs.
TEST_FEATURES :=
# Twice, because a feature-gated module is not compiled at all without its
# feature: the plain pass proves the crate is usable with nothing turned
# on, and the second is the only one that sees the modules.
:
# Same two passes, and here the second one is load-bearing for a different
# reason: cargo silently *skips* an example whose `required-features` are
# unmet rather than reporting it, so without it an example can rot
# indefinitely while the build stays green.
:
# `--lib` because the examples are Pi images, and the bare-metal
# dev-dependencies they link are excluded from a host build on purpose.
:
:
:
# `--examples` included so the lint runs over them too: they are the only
# code here that talks to hardware, which makes them the code most likely
# to earn a lint.
:
# `-D warnings` is the whole point: a plain doc build almost never fails,
# so without it this catches nothing. What it does catch is broken
# intra-doc links -- including the non-obvious case where a module's own
# `//!` links resolve in the *crate root's* scope, because they get merged
# with the outer doc comment on the `pub mod` declaration in lib.rs.
#
# The same enumerated set as everything above, and for the same reason: a
# feature-gated module is otherwise not documented at all, and so not
# checked at all. It matches `[package.metadata.docs.rs]`, so what this
# builds is what the published page will be.
:
# What `cargo publish` will verify: it builds the packaged tarball, which
# catches the "works in this working copy, broken on crates.io" class of
# problem. Through scripts/ci/package-verify.sh, so the build uses this
# repository's rpi-hal, rpi-hal-embassy and rpi-loader-ota rather than the
# published ones, and a change spanning them verifies before they are
# released. That script explains the rest, including why it keeps its own
# target directory.
:
:
: