RTEMS | build: Fix stale build artifacts after reconfiguration (!1362)

[Sebastian Huber (@sebhub)]

Sebastian Huber created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1362

Project:Branches: sebhub/rtems:fix-build-deps to rtems/rtos/rtems:main
Author:   Sebastian Huber
Assignee: Sebastian Huber


## Background

Changing the build configuration and re-running `./waf configure` could leave
stale artifacts in the build tree, because two kinds of configuration-driven
dependencies were not tracked by the build:

1. Header changes were missed for tests built via the `bld.cc()` / `bld.cxx()`
   helpers, so a changed `cpukit/include/rtems/score/cpuopts.h` (e.g. after
   toggling `RTEMS_SMP`) did not recompile the affected objects, producing
   linker errors against symbols such as `_Per_CPU_Information` and
   `_SMP_Processor_configured_maximum`.

2. Generated linker scripts (e.g. `spec/build/bsps/arm/fvp/linkcmds.yml`) were
   not a dependency of the link step, so a reconfiguration that changed the
   memory layout did not relink the test executables.

Issue #5482 was previously worked around by hard-coding `cpuopts.h` as an
explicit dependency of the affected tests (!1249). This series removes that
workaround and fixes the root causes in the build system instead.

## Changes

* **build: Use compiler-generated deps for cc()/cxx()** — The helpers compiled
  through a raw `rule=` string, which `gccdeps.py` does not wrap, so the
  compiler-generated `.d` files were never evaluated. New `c_explicit_target` /
  `cxx_explicit_target` features (analogous to the existing `asm_explicit_target`)
  create genuine `c` / `cxx` tasks that `gccdeps.py` wraps, so automatic header
  dependency tracking works. Extra generated-header dependencies are kept as
  `dep_nodes` to preserve clean-build ordering.

* **Revert "build: Add explicit dependencies"** — Reverts the `cpuopts.h`
  workaround, which the first commit makes unnecessary.

* **build: Relink executables if a linkcmds changes** — Adds the
  configuration files collected in `env.cfg_files` (which include the generated
  linker scripts) as dependencies of every executable link task: the standard
  `cprogram`/`cxxprogram` links via `process_start_files()`, the custom `link()`
  task used by `link_cc()` / `link_cxx()`, and the `gnatmake()` task.

The net change is to `wscript` only; the reverted `spec/*.yml` files return to
their original state.

## Testing

All testing was done with the `aarch64/zynqmp_apu` BSP and the `aarch64-rtems7`
toolchain.

**Compiler-generated dependencies (commit 1):**
- Reproduced the original failure: with the `cpuopts.h` workaround reverted and
  `RTEMS_SMP` toggled via reconfiguration, the pre-fix tree failed to relink
  `dl06` and others with undefined references to the SMP/per-CPU symbols.
- After the fix, `-MMD` `.d` files are produced for the helper-built objects and
  list `cpuopts.h`. Toggling `RTEMS_SMP` in both directions (True→False and
  False→True) via reconfiguration recompiled the affected objects (e.g.
  `dl06/pre-init.c`) automatically from the generated dependency files, and the
  full build (2035 tasks, all `dl*` / `tar*` / `psxftw01`) linked cleanly.

**Linker-script dependency (commit 3):**
- Isolated test: modifying only the generated `build/aarch64/zynqmp_apu/linkcmds`
  (as a linker-script-only reconfiguration would) triggered a relink of all 155
  executables — 140 standard `cprogram`/`cxxprogram` links and 15 custom
  `link_cc`/`link_cxx` (`dl*` / `tar*`) links — with zero recompilations,
  confirming both link paths now depend on the linker script.
- End-to-end: changing `BSP_XILINX_ZYNQMP_NOCACHE_LENGTH` and reconfiguring
  regenerated the linker script and relinked the executables.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1362
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-8mommlux5hfaaexo7w3mlrzzv-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260722/4b45b03a/attachment-0001.htm>