avr/ds3231
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

build: libavr rides as the pinned submodule

Browse Source 
The submodule replaces FetchContent and the unpinned forge fallback;
LIBAVR_ROOT stays as the tandem-development override, the presets take the
toolchain file from the submodule, and the Studio project's include path
anchors there — correct by construction.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
BlackMark
2026-07-28 00:29:38 +02:00
parent 0ecd53856b
commit d219b299f4
7 changed files with 33 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
README.md
View File

@@ -14,10 +14,13 @@ auto now = rtc::read_clock(); // result<date_time>
(void)rtc::set_alarm1({}, ds3231::alarm1_rate::once_per_second);
```
`example/main.cpp` is the full tour. Build with a libavr checkout:
`example/main.cpp` is the full tour. libavr rides as the `libavr/` submodule,
pinned to the commit this driver builds against; `LIBAVR_ROOT` (cache or
environment) overrides it for development against a working tree:
```sh
LIBAVR_ROOT=/path/to/libavr cmake --preset attiny85-generated
git submodule update --init libavr
cmake --preset attiny85-generated
cmake --build --preset attiny85-generated
```
@@ -39,13 +42,14 @@ dir>/<Configuration>` whatever `OutputDirectory` says, so two projects sharing
one directory would also share one `example/main.o`, and building one after the
other without a rebuild would link the other part's object.
Studio expects libavr checked out **beside this repo** and finds it at
`$(MSBuildProjectDirectory)\..\..\libavr\include` — anchored to the project,
because a plain relative path is resolved against the generated makefile's
directory (the configuration's output directory), not the project's. There is no
`LIBAVR_ROOT` escape hatch: a variable exported in a shell is invisible to Studio
launched from the Start menu. It also needs a GCC 16.1 toolchain registered as
flavour `avr-g++-16.1.0`, nothing older reaching `-std=c++26`.
Studio finds libavr in the **submodule** at
`$(MSBuildProjectDirectory)\..\..\libavr\include` — correct by construction,
and anchored to the project because a plain relative path is resolved against
the generated makefile's directory (the configuration's output directory), not
the project's. There is no `LIBAVR_ROOT` escape hatch: a variable exported in a
shell is invisible to Studio launched from the Start menu — which is what the
submodule answers. It also needs a GCC 16.1 toolchain registered as flavour
`avr-g++-16.1.0`, nothing older reaching `-std=c++26`.
One generated file is required before the project will load, and one command
checks the flags have not drifted (both from libavr's `tools/atmelstudio/`):
@@ -53,9 +57,9 @@ checks the flags have not drifted (both from libavr's `tools/atmelstudio/`):
```sh
for mcu in atmega328p attiny85; do
case $mcu in atmega328p) device=ATmega328P;; attiny85) device=ATtiny85;; esac
python ../libavr/tools/atmelstudio/componentinfo.py \
python libavr/tools/atmelstudio/componentinfo.py \
"ide/$mcu/ds3231-$mcu.componentinfo.xml" --device "$device"
python ../libavr/tools/atmelstudio/check-flags.py --solution ide/ds3231.atsln \
python libavr/tools/atmelstudio/check-flags.py --solution ide/ds3231.atsln \
--project "ds3231-$mcu" \
--compile-commands "build/$mcu-generated/compile_commands.json" \
--log "build/as-$mcu.log"