BlackMark
52faaf9920
The pin moves to libavr's USI I2C rate fix and to the two override surfaces the fan-controller port filed - a PWM solve that can be pinned, and a capture edge that is a value rather than a template argument. Nothing here names any of them; four presets green and no image moved. `tools/check.sh` is new, and its absence was the defect: this repository had no committed gate at all, so "run the suite" was a snippet somebody remembered - and the order in a snippet is the one thing nobody re-derives. Every preset built before any is tested is subtle and load-bearing, because the mode-identity check reads the sibling mode's tree and a build-then-test-per- preset run holds a fresh image against a stale sibling. The loop is libavr's `tools/check-presets.sh`; nothing is written after the call, there being nothing beyond the presets this repository knows to ask. And `.vscode/settings.json` stops naming a toolchain prefix. It named `D:/dev/libavr/local/toolchain/avr-gcc-16.1.0-mingw`: a path true of one machine (libavr guidance rule 50) and, since the in-repo toolchain copies went, true of none. `local/machine.cmake` is where a checkout says that, and it already did. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
12 lines
605 B
Bash
Executable File
12 lines
605 B
Bash
Executable File
#!/usr/bin/env bash
|
|
# The task gate: every configure preset built, and only then every one tested.
|
|
#
|
|
# The loop itself is libavr's (tools/check-presets.sh) because the order in it
|
|
# is subtle and was got wrong by hand more than once - the mode-identity checks
|
|
# read the sibling mode's tree, so a build-then-test-per-preset run compares a
|
|
# fresh image against a stale sibling. Anything this repository needs beyond
|
|
# the presets is written after the call, where every tree is built and tested.
|
|
set -euo pipefail
|
|
cd "$(dirname "${BASH_SOURCE[0]}")/.."
|
|
"${LIBAVR_ROOT:-libavr}/tools/check-presets.sh" "$@"
|