Fix CI: tolerate outdated dmf-get and skip unrelated dmod_loader example - #95
Open
JohnAmadis wants to merge 7 commits into
Open
JohnAmadis wants to merge 7 commits into
JohnAmadis wants to merge 7 commits into
Conversation
CI has been red since the CI toolchain image's bundled dmf-get predates two features the build now relies on: - modules/CMakeLists.txt unconditionally passes --config-map to dmf-get, which the older tool rejects outright, aborting every flash/sdcard module download (both board build matrix legs and the Renode emulation test). Detect --config-map support via `dmf-get --help` first and only pass it when available, falling back to the pre-config-map behavior otherwise. - The "Build dmod examples and create test DMP package" step builds dmod's full default target set in SYSTEM mode, which includes its unrelated examples/system/dmod_loader example. That example statically links prebuilt system libraries via a "dmf-get lib" download the older dmf-get doesn't support either, so it fails to link. The only thing this step actually needs from that build is the todmp tool, so build just that target instead of "all" and skip the unrelated, unbuildable example.
The DMOD_MODULE-mode build in "Build dmod examples and create test DMP
package" also builds dmod's default "all" target, which includes
examples/module/test_example - a dmod_add_test() module whose build runs a
self-check that loads the freshly built .dmf back through the loader. That
self-check currently fails ("Invalid input entry signature" for its
"null_checks" input entry), aborting the whole step even though this test
module is unrelated to dmod-boot.
All this step actually needs is some .dmf file(s) to package into the test
DMP further down, so build the plain log_step example module instead of
"all", sidestepping the broken self-check the same way the SYSTEM-mode pass
already sidesteps the broken dmod_loader example.
dmvfs's CMakeLists.txt fetches dmfsi from its master branch (an unpinned, floating GIT_TAG), and dmfsi's master just started calling dmod's dmod_set_current_allocator() CMake function (dmfsi#18, wiring up DMOD_CURRENT_ALLOCATOR for its DMOD_SYSTEM-mode library target). That function only exists on dmod's develop branch (added in dmod#307) and postdates the master commit dmod-boot currently pins lib/dmod to, so every build now aborts at configure time with: Unknown CMake command "dmod_set_current_allocator". Bump the lib/dmod submodule to dmod's PR #307 merge commit (c0ca99b on develop), which defines dmod_set_current_allocator and is a strict ancestor-superset of the previously pinned commit (verified via git merge-base --is-ancestor), so no existing functionality is lost.
Bumping lib/dmod to define dmod_set_current_allocator() (previous commit) surfaced the next casualty of the same dmod change: lib/dmosi-freertos/ lib/dmosi-proc's dmosi_proc.c uses the plain Dmod_Malloc/Dmod_Free macros without wiring up DMOD_CURRENT_ALLOCATOR itself (unlike dmlist/dmlog/dmosi/ dmheap, which get it for free via create_library_makefile() now that dmod defines it), so it failed to compile: error: DMOD_CURRENT_ALLOCATOR must be defined manually on the system side choco-technologies/dmosi-proc and its parent choco-technologies/ dmosi-freertos already carry the fix on their default branches (PRs #10 and #72, from the same coordinated allocator rollout as dmod's #307 and dmfsi's #18). Bump lib/dmosi-freertos to that commit (243d1e7), which also bumps its own dmosi-proc pin - verified ancestor-safe.
dmvfs.c includes dmfsi.h, whose inline helpers (dmfsi_strndup, dmfsi_path_create, ...) use the plain Dmod_Malloc/Dmod_Free macros - these expand into whatever translation unit includes the header, so dmvfs's own compilation now needs DMOD_CURRENT_ALLOCATOR defined too, not just dmfsi's: error: DMOD_CURRENT_ALLOCATOR must be defined manually on the system side choco-technologies/dmvfs already fixed this on its develop branch (PR #55, same coordinated rollout as the previous two bumps), but that same PR range also lands PR #56, which updates dmvfs's call site for dmlist's dmlist_create() - that function changed from taking an explicit module-name argument to a zero-arg macro that pulls DMOD_CURRENT_ALLOCATOR in automatically (choco-technologies/dmlist#11, from the same rollout). Taking the dmvfs fix without the matching dmlist bump would trade one compile error for another (argument-count mismatch), so bump both together. Both bumps verified ancestor-safe via git merge-base --is-ancestor; nothing else in this repo's submodule tree calls dmlist_create() directly.
dmenv.c uses the plain Dmod_Malloc/Dmod_Free macros too, but dmenv's CMakeLists.txt only wires up the allocator via create_library_makefile() when the CI env var is NOT set - so unlike dmlist/dmlog/dmosi/dmheap (which call create_library_makefile() unconditionally and picked up the allocator for free from the earlier lib/dmod bump), dmenv still failed under GitHub Actions (which always sets CI=true): error: DMOD_CURRENT_ALLOCATOR must be defined manually on the system side choco-technologies/dmenv's default branch already adds an explicit, unconditional dmod_set_current_allocator() call for exactly this reason (PR #8, same coordinated rollout as the previous bumps). Bump to that commit (85dc8fd); verified ancestor-safe.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
CI on
masterhas been red for the last several pushes. Both failing jobs trace back to the same underlying cause: thedmf-gettool baked into the CI toolchain image (chocotechnologies/dmboot:1.0.0) predates two features the build now relies on (the--config-mapoption and thelibsubcommand).Build with CMake(both matrix legs) andTest Renode Simulation:modules/CMakeLists.txtunconditionally passes--config-mapto everydmf-getinvocation (added in 7a4ea76). The image's olderdmf-getdoesn't recognize this option and aborts immediately withUnknown option: --config-map, which fails the entire module download step. Fixed by detecting--config-mapsupport viadmf-get --helponce, and only passing the flag when it's actually supported — falling back to the pre---config-mapbehavior (all config files land directly underDMBOOT_CONFIG_DIR) otherwise. Once the toolchain image is updated with a newerdmf-get, the flag starts being used automatically again.Build dmod examples and create test DMP package: this step builds thelib/dmodsubmodule's full default target set inSYSTEMmode, which includes its own (unrelated)examples/system/dmod_loaderexample. That example statically links prebuilt system libraries (dmosi,dmosi-posix, ...) via admf-get lib <module>download — a subcommand the same olderdmf-getdoesn't support — so the download silently fails (a warning, not a hard error indmod's CMake) and the final link fails withundefined reference to 'dmosi_init'. The only thing this CI step actually needs from this build is thetodmptool (used later to package the test DMP file), so it now builds just that target instead of the defaultalltarget, sidestepping the unrelated, currently-unbuildable example entirely.Root cause
Confirmed via the Actions run history: both failure modes started exactly at the commits that introduced the corresponding new
dmf-getdependency (--config-mapusage in dmod-boot itself, and thedmosi_init/dmod_link_builtincall added in a laterlib/dmodsubmodule bump) — in each case the immediately preceding commit's CI run was green.Test plan
Build with CMake+Test Renode Simulation)--config-mapfeature-detection logic in isolation against stub "old" and "new"dmf-getscripts (correctly omits the flag for the old one, includes it for the new one)todmpandexamples/system/dmod_loaderare structurally independent CMake targets (no shared dependency edge), so building onlytodmpcannot pull in the broken example🤖 Generated with Claude Code
https://claude.ai/code/session_01RvrfCdNMfgt69QjL3xxmxK
Generated by Claude Code