Fix NAV_MAX_WAYPOINTS redefinition breaking FISHDRONEF4 build

[sensei-hacker]

Summary

target/common.h unconditionally defines NAV_MAX_WAYPOINTS (120). FISHDRONEF4/target.h and src/test/unit/target.h each override it to 60 with a bare #define instead of the #undef+#define pattern used elsewhere in the tree (e.g. SITL/target.h) for this same situation. Under -Werror this is a fatal "redefined" diagnostic that breaks the FISHDRONEF4 build.

This is pre-existing tech debt from a 2016 consolidation of NAV_MAX_WAYPOINTS into common.h (and a same-day follow-up cleanup pass) that missed these two files — not something introduced by any recent change. Checked all 231 target.h files under src/main/target/ for any other occurrence; these are the only two affected.

Changes

• Add #undef NAV_MAX_WAYPOINTS immediately before the existing override in src/main/target/FISHDRONEF4/target.h.
• Same fix in src/test/unit/target.h.
• No resolved value changes — NAV_MAX_WAYPOINTS remains 60 for both targets, before and after.

Testing

• FISHDRONEF4 build with -DWARNINGS_AS_ERRORS=ON: failed before the fix ("NAV_MAX_WAYPOINTS" redefined [-Werror]), builds clean after (0 warnings/errors, confirmed by reverting the fix and rebuilding in a separate clean directory to verify causation, not just correlation).
• mavlink_unittest (top-level CMake, -DTOOLCHAIN=none): 62/62 passing, no regressions.

Code Review

Reviewed with the inav-code-review agent — approved, no issues found. Confirmed the fix matches existing codebase convention (SITL/target.h) and doesn't change any resolved configuration value.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[breadoven]

Isn't the #define NAV_MAX_WAYPOINTS for FISHDRONEF4 an oversight from when the target was first created back in 2016. 120 waypoints shouldn't be an issue for this F405 board surely ? Why not remove the 60 waypoint limit from both the affected targets ?

[sensei-hacker]

Isn't the #define NAV_MAX_WAYPOINTS for FISHDRONEF4 an oversight from when the target was first created back in 2016. 120 waypoints shouldn't be an issue for this F405 board surely ? Why not remove the 60 waypoint limit from both the affected targets ?

I don't know why they set that. Maybe they had a good reason , maybe not. It has been SKIP_RELEASES for 10 years, so I don't suppose it matters much. 60 is a lot of waypoints anyway. :)

[breadoven]

Isn't the #define NAV_MAX_WAYPOINTS for FISHDRONEF4 an oversight from when the target was first created back in 2016. 120 waypoints shouldn't be an issue for this F405 board surely ? Why not remove the 60 waypoint limit from both the affected targets ?

I don't know why they set that. Maybe they had a good reason , maybe not. It has been SKIP_RELEASES for 10 years, so I don't suppose it matters much. 60 is a lot of waypoints anyway. :)

NAV_MAX_WAYPOINTS was set for each target originally. Then around the time FISHDRONEF4 was added NAV_MAX_WAYPOINTS was removed from the each target and moved to common.h. NAV_MAX_WAYPOINTS probably got overlooked and left in the FISHDRONEF4 target.h file at that time. Anyway if it's SKIP_RELEASES it doesn't really matter.