Repository navigation
fix(compdb): reject conflicting -D values and forward the driver flags - #44
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Conflict detection rejects equivalent definitions and blocks configurations explicitly supplied through an options header.
2 open issues
What changed in this PR
Updates the compilation-database SBOM frontend to detect conflicting macro values and forward configuration and metadata to the driver.
Changes:
- Adds conflict diagnostics with example source files.
- Forwards identity and dependency flags and supports
--options-h. - Adds frontend tests and runs them in CI.
| File | Description |
|---|---|
| tests/test_compdb_sbom.py | Tests conflict handling and driver argument forwarding. |
| share/frontends/compdb_sbom.py | Adds conflict detection and driver options. |
| .github/workflows/selftest.yml | Includes the new frontend tests in CI. |
Review effort: Balanced
Frauschi
force-pushed
the
fix/compdb-conflicting-defines
branch
from
October 19, 2026 18:01
210c32c to
5994232
Compare
Frauschi
force-pushed
the
fix/compdb-conflicting-defines
branch
2 times, most recently
from
October 22, 2026 12:37
25e8091 to
516f764
Compare
compdb_sbom.py merged the -D tokens of every selected compile command into one set. When two entries defined the same macro with different values (-DFOO=10 in one, -DFOO=2 in another), both tokens reached the capture and whichever the compiler saw last won, so the SBOM recorded a configuration that matched neither build. The frontend now keys the merged set by macro name and exits with the macro, each value and an example file when the selected entries disagree, pointing at --include/--exclude to split the database into one configuration per SBOM. A bare -DFOO counts as -DFOO=1, as the compiler defines it. A macro that only some entries define still merges as before, since per-file -D flags are normal. With --options-h the -D tokens are not captured, so their conflicts are not checked. The frontend also dropped flags the driver supports, so a compdb SBOM fell back to the inferred licence, listed no wolfSSL dependency and could not use a pre-expanded header. It now forwards --license-override, --license-text, --supplier, --component-type, --dep-wolfssl, --dep-wolfcrypt, --dep-openssl and --dep-version, and accepts --options-h in place of the -D capture. --options-h with --settings-h or --include-dir is an error, since those only feed the capture. tests/test_compdb_sbom.py covers the conflict, the merge, --exclude as the way out, and the forwarding through a stub driver. It is wired into selftest.yml.
…e -include A Zephyr build's compile_commands.json lists every kernel, driver and application file next to the module's sources. compdb_sbom.py checked --root before --include/--exclude, so each of those files printed a "skipping source outside --root" warning even when the include filter would have dropped it anyway: about 200 lines for wolfssl and 285 for wolfCert. The filters now run first, and only a selected source outside --root is warned about. The driver also refused a relative --settings-h unless it existed under the current directory, although the compdb help gives wolfssl/wolfcrypt/settings.h as the example. It now checks only an absolute path and leaves a relative one to the compiler's -include search, which tries the current directory, then the -I dirs in --cflags, then each --include-dir. --include and --exclude gain help text saying they are re.search patterns, not globs.
Frauschi
force-pushed
the
fix/compdb-conflicting-defines
branch
from
October 22, 2026 13:11
516f764 to
58a9376
Compare
sameehj
approved these changes
Oct 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while integrating wolfCert.
compdb_sbom.pymerged every entry's-Dtokens into one set, so-DFOO=10in one file and-DFOO=2in another both reached the capture and the SBOM recorded a configuration that matched neither. It now exits with the macro, each value and an example file, and points at--include/--exclude. A macro that only some entries define still merges as before.--license-override,--license-text,--supplier,--component-type,--dep-wolfssl,--dep-wolfcrypt,--dep-openssland--dep-version, and accepts--options-hin place of the-Dcapture. Before, these SBOMs fell back to the inferred licence and listed no wolfSSL dependency.