RTEMS | Draft: build: Add a clangdb command to emit compile_commands.json (!1443)

[Sam Price (@TheSamPrice)]

Sam Price created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1443

Project:Branches: TheSamPrice/rtems:build/waf-clangdb to rtems/rtos/rtems:main
Author:   Sam Price



Static analysis without the real compiler flags is not analysis of the
build.  Given no compilation database, cppcheck brute-forces #ifdef
combinations and analyses guesses, and include paths have to be supplied
by hand.  A database also defines the analysis scope in a way that can be
written down: everything the build compiled, rather than a directory
somebody picked.

This adds waftools/clang_compilation_database.py, stock upstream Waf
2.1.4 matching the Waf bundled with RTEMS, and loads it.  Because RTEMS
dispatches every command through variants, per-variant clangdb_<variant>
commands are registered alongside the existing build, clean, install and
uninstall ones, so ./waf clangdb behaves like the other commands rather
than only working for a default variant.

It emits every translation unit with the exact flags used: 3440 for
riscv/rv32imafdc.  ./waf build is unaffected.

bear and intercept-build are not an alternative here.  RTEMS's Waf
resolves the cross compiler at configure time into
build/c4che/<arch>/<bsp>_cache.py and never consults $CC, so CC-override
interception sees nothing, and library interposition is unreliable on
macOS under SIP.

Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
Signed-off-by: Samuel Price <thesamprice at gmail.com>

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1443
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-4rz2uh50mq83igai5li1lgjz8-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/20260821/95e1e87a/attachment.htm>