RTEMS | waf: Track cpuopts.h as compilation dependency (!1093)
SHIVAM DEOLANKAR (@D3athSkulll)
gitlab at rtems.org
Mon Apr 13 17:27:38 UTC 2026
SHIVAM DEOLANKAR commented on a discussion on wscript: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1093#note_148492
> def cc(self, bld, bic, source, target=None, deps=[], cppflags=[]):
> if target is None:
> target = os.path.splitext(source)[0] + ".o"
> +
> + cpuopts = bld.bldnode.make_node("cpukit/include/rtems/score/cpuopts.h")
I first implemented a configuration fingerprint to invalidate builds when RTEMS_SMP changes, which resolved the linker errors.
Following your advice, I tried adding cpuopts.h as an explicit dependency via the deps mechanism in TestProgramItem, LibraryItem, and ObjectsItem. However, this did not fix our issue - stale objects were still reused.
Then I inspected gccdeps.py. The .d files correctly include cpuopts.h and it is resolved into node dependencies, so dependency detection works. However, even when cpuopts.h changes after reconfiguration, dependent tasks are not rebuilt, suggesting the task signature is not invalidated.
So the issue appears to be with signature invalidation for generated headers rather than missing dependencies. The configuration fingerprint solution works because it forces the task signature to change.
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1093#note_148492
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260413/a4ff51e1/attachment.htm>
More information about the bugs
mailing list