Repository navigation
Clean only the named target in clean_<target> - #11909
sensei-hacker merged 4 commits into
Conversation
clean_<target> ran the generator clean in the build directory, so it wiped every target instead of the one that was named. Remove the artefacts of that target instead: its binary, map file, object files, generated settings and the hex/bin files built from it. Neither "make clean" nor "ninja clean" can be limited to a single target, so the paths are removed by a small cmake script. That keeps the behaviour identical for the Makefile and the Ninja generator. The object directory itself is kept, because the Makefile generator stores the build rules of the target (build.make, DependInfo.cmake, ...) next to the object files and without them the next build fails until cmake is run again. at32, rp2350 and sitl carried the same code and now share add_clean_target() with stm32. Fixes iNavFlight#6135
getMotorAveragePeriod() was guarded by USE_ESC_SENSOR_TELEMETRY and USE_DSHOT_TELEMETRY. Neither of them exists in INAV, so only the #else branch was ever compiled. The guarded code also calls getEscSensorData(), a Betaflight API; INAV has escSensorGetData() and getEscTelemetry(). The function stays, srxlFrameRpm() still calls it and reports the RPM field as unused. Only the branches go, together with the defines and the esc_sensor.h include that nothing else used. Fixes iNavFlight#11298
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
PR Summary by QodoScope clean targets and remove dead Spektrum RPM telemetry code
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can switch off images and animations for a plain-text comment |
|
Tested the clean part with the Makefile generator. The per-target scope works (MATEKF722SE stays untouched and
Literal paths (the output directories are known) instead of generator expressions would avoid the dependency. Please drop the srxl.c commit from this PR: #11605 ports exactly that block to INAV's escSensorGetData() and needs the constants removed here, so the two would conflict. That PR is the right fix for #11298. With that the PR is also down to one topic. |
This reverts commit 119a245. iNavFlight#11605 replaces the same block with a working escSensorGetData() path and still uses MICROSEC_PER_MINUTE, SPEKTRUM_MIN_RPM and SPEKTRUM_MAX_RPM, so removing them here would conflict with it. iNavFlight#11298 is left to that PR and this PR keeps to the clean target only.
$<TARGET_FILE:...> and the other target generator expressions in the COMMAND of add_custom_target() add a target-level dependency on that executable. clean_<target> therefore built the main, _bl and _for_bl executables before deleting them: on an unbuilt tree clean_MATEKF722 compiled about 1200 objects and linked three ELFs, and the clean failed outright where the _for_bl image does not fit into flash. Pass literal paths instead. The executable lives in the target's RUNTIME_OUTPUT_DIRECTORY and the map file follows the naming of generate_map_file(), so the list of removed files is unchanged.
|
Both points addressed:
Heads-up: 119a245 still carries Retested after a |
|
RAM / Flash usage vs. base commit
See RAM/flash optimization guide for techniques to reduce usage. |
|
Test firmware build ready — commit Download firmware for PR #11909 251 targets built. Find your board's
|
Problem
#6135 (stronnag): after
make MATEKF405 WINGFC MATEKF722,make clean_MATEKF405removes the build output of every target, so the nextmake MATEKF722is a full rebuild instead of a no-op. Fixes #6135.Cause
clean_<name>runs the generator's global clean (COMMAND ${generator_cmd} cleanin${CMAKE_BINARY_DIR});<name>is never used. The same block sits incmake/stm32.cmake,cmake/at32.cmake,cmake/rp2350.cmakeandcmake/sitl.cmake.Change
add_clean_target()incmake/main.cmakeplus the scriptcmake/clean_target.cmake, run withcmake -P, so it behaves the same for Make and Ninja. stm32, at32, rp2350 and sitl pass their executables and output files (hex/bin/uf2/exe, plus the bootloader variants and the combined hex where they are built). The helper adds each executable's ELF and its map file where one is generated, the target's generated settings files and the*.o/*.obj/*.dfiles underCMakeFiles/<exe>.dir. The directory itself stays, because the Makefile generator keepsbuild.makethere. All paths are literal: a$<TARGET_FILE:...>in the command would makeclean_<name>build the target before deleting it.Test
Local Linux build, CMake 4.4.3, Ninja 1.13.2, GNU Make 4.4.1, Release,
WARNINGS_AS_ERRORS=ON.ninja MATEKF405 MATEKF722. Before this PR,ninja clean_MATEKF405deleted 1107 files (550 MATEKF405, 557 MATEKF722) andninja -n MATEKF722then had 551 objects to compile. With this PR,ninja clean_MATEKF722deletes 558 files, all of them MATEKF722's: the same 557 plusbin/MATEKF722.elf.map, whichninja cleandoes not know about and left behind.ninja -n MATEKF405then has no object to compile (only the hex step, which always runs).ninja MATEKF722rebuilds to the same size.ninja -n clean_<X>on an unbuilt tree: 1 step for MATEKF405, MATEKF722, MATEKF722SE, MATEKF405SE, IFLIGHT_BLITZ_ATF435 and RP2350_PICO. Nothing is built.make clean_MATEKF405without re-running cmake.make clean_MATEKF722SEon an unbuilt tree compiles nothing.clean_SITLremoves only the SITL build output.clean_<target>, so CI only confirms that every target still configures.Flash / RAM
No source file changes. MATEKF722 and MATEKF405 text/data/bss are identical to the base.
Docs
None needed.
docs/development/Building in Linux.md("Cleaning") andbuild.shalready describeclean_<target>as cleaning one target; this PR makes that true.