BlackMark
2cdf56f8d6
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>
10 lines
144 B
Plaintext
10 lines
144 B
Plaintext
build/
|
|
.cache/
|
|
|
|
# Atmel Studio: generated per machine, and its build outputs
|
|
ide/*.componentinfo.xml
|
|
ide/Debug/
|
|
ide/Release/
|
|
ide/.vs/
|
|
ide/*.log
|