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>
Three things the solution got wrong, all found by opening it in the GUI rather
than building it headlessly.
The project listed only main.cpp, so none of the headers could be opened from
Solution Explorer. Every source and header is listed now, with <Link> mirroring
the on-disk src/ layout, which is what master's project did.
Neither configuration compiled in the GUI: libavr was found through
$(LIBAVR_ROOT), and a variable exported in a shell is not visible to Studio
launched from the Start menu. Release only looked healthy because its objects
were already up to date from a headless build. The path is now anchored to the
project directory, which also side-steps a second trap: a plain relative include
is resolved against the generated makefile's own directory, the configuration's
output directory, not the project's. Pinning libavr as a submodule would remove
the assumption that the two sit side by side, and is on libavr's task list.
Both configurations verified with LIBAVR_ROOT deliberately unset, Release still
byte-identical to the CMake build and the flag gate still green. Debug's own
translation unit carries DWARF-4 as intended.
Studio's per-user state under ide/.vs/ and the build logs are ignored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
master opens in Studio, so this branch should too. One project, the port's own
chip, flags mirrored by hand against the CMake build — and the acceptance is
not that it builds but that it builds the same firmware: .text (7094 B) and
.data (336 B) come out byte-identical to the CMake output from the same
sources.
libavr is found through $(LIBAVR_ROOT), the variable the CMake build already
uses, so no machine path is committed; Studio expands it from the environment.
The toolchain is named by flavour only, since nothing Studio ships can compile
-std=c++26 and the path to one that can is per-machine state.
The componentinfo file the project cannot load without is generated by
libavr's tools/atmelstudio/componentinfo.py and ignored here, as are Studio's
output directories. Release is what the flag gate compares, the presets
defining no debug build; Debug carries the -Og -gdwarf-4 pair libavr's own
debug preset uses.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
