mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-05-22 06:14:14 +08:00
Daniel Fanache
b990430cdc
* fix(cmake): use Python3 module; cache PYTHON_EXECUTABLE properly The legacy `find_package(PythonInterp 3)` is deprecated (warned with noisy CMP0148 by cmake 3.27+, currently visible on Ubuntu 24.04 CI runs). It also stores its result as PYTHON_EXECUTABLE without a proper CACHE type, which interacts badly with the Makefile's `cmake-cache-check`. `cmake -L` skips UNINITIALIZED entries, so the `-DPYTHON_EXECUTABLE=...` passed by the top-level Makefile is never matched in the cache and every invocation forces a full reconfigure. Switch to `find_package(Python3 COMPONENTS Interpreter REQUIRED)`, then bridge to the legacy `PYTHON_EXECUTABLE` name that the rest of the codebase still references. Promote it to a CACHE FILEPATH entry so cmake -L lists it, preserving any user-supplied value verbatim (find_package(Python3) canonicalises e.g. bin/python3 to bin/python3.13, defeating a string-based cache match). Signed-off-by: Daniel Fanache <dan@rts.ro> * fix(cmake): promote CONFIG to CACHE STRING for incremental builds When CONFIG is passed via `-DCONFIG=...` on the cmake command line, it is stored as an UNINITIALIZED cache entry. `cmake -L` skips UNINITIALIZED entries by design, so the Makefile's `cmake-cache-check` (which uses `cmake -L` to diff desired vs cached options) never finds CONFIG in the output, concludes the cache is stale, and triggers a full reconfigure on every `make <target>` invocation. If a config identifier is given, we force promote it to CACHE STRING. This preserves the user supplied value as it was, while making it visible to `cmake -L`, so the cache-check succeeds when nothing has changed. Signed-off-by: Daniel Fanache <dan@rts.ro> * fix(cmake): track default.px4board as a configure dependency Non-default labels merge `default.px4board` + `{label}.px4board` via `merge_config.py`, but only the label file was listed as a configure dependency. Changes to `default.px4board` were silently ignored until a clean build, which is surprising and easy to debug for hours. Register `default.px4board` as a CMAKE_CONFIGURE_DEPENDS in the non-default-label branch so edits trigger reconfigure as expected. Signed-off-by: Daniel Fanache <dan@rts.ro> * fix(cmake): correct NuttX apps/library build dependency tracking Three dependency graph defects in the libapps.a and per NuttX library custom_commands caused either spurious full rebuilds or stale outputs on incremental builds. (1) `builtin_list.h` and `builtin_proto.h` are regenerated by the apps build from `px4.bdat`/`px4.pdat` on every invocation. They were included in `nuttx_apps_files`, so on each build we saw them as changed inputs and re-triggered the apps target perpetually. Exclude them with a `list(FILTER)`. (2) libapps.a's custom_command lacked `px4.bdat`/`px4.pdat` as dependencies, so module additions or renames (which regenerate those registries) did not propagate to a rebuild of the builtin command table. Add them to DEPENDS. (3) NuttX's recursive make does not always notice that `builtin_list.h` has been regenerated and that `builtin_list.c` therefore needs recompiling. Touch `builtin_list.c` so NuttX's make picks up the indirect change. Additionally, drop the destructive cleanup COMMANDs that ran at the start of libapps.a and each per-library custom_command (`remove -f *.a`, `find ... -delete *.o`). These were workarounds for the now fixed dependency tracking; without them removed, they would also force unnecessary full rebuilds every time. Signed-off-by: Daniel Fanache <dan@rts.ro> --------- Signed-off-by: Daniel Fanache <dan@rts.ro> Co-authored-by: Ramon Roche <mrpollo@gmail.com>