Skip to content

refactor: Compute compile flags once per target - #303

Open
nettle wants to merge 2 commits into
Ericsson:mainfrom
nettle:implementation-deps
Open

refactor: Compute compile flags once per target#303
nettle wants to merge 2 commits into
Ericsson:mainfrom
nettle:implementation-deps

Conversation

@nettle

@nettle nettle commented Aug 24, 2026

Copy link
Copy Markdown
Collaborator

Why:
Dependency flags, copts and built-in include directories
were recomputed for every source file of a target,
and get_compile_flags mixed two concerns:
flags of the given CcInfo target and walking deps of ctx.rule.attr.
That made the handling of implementation_deps hard to follow.

What:

  • Split to get_compile_flags() and get_implementation_deps_flags()
  • Collect dependency flags once per target and drop duplicates
  • Move copts and built-in includes out of the per source loop
  • Do not collect local_defines for implementation_deps
  • Drop unused target parameter, compile_flags, compile_variables
  • Add the once pattern to unit_test() to detect duplications
  • Add tests for implementation_deps, flag propagation via deps,
    local_defines and deduplication

Addresses:
#304, #305, #306, #307

@nettle nettle changed the title Compute compile flags once per target refactor: Compute compile flags once per target Aug 24, 2026
@nettle nettle added the enhancement New feature or request label Aug 24, 2026
@furtib
furtib requested review from Szelethus and furtib and removed request for Szelethus August 25, 2026 09:00

@furtib furtib left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, you also outsourced the flag collection to a single function and call implementations on that too, fixing the flag mismatches.
But you also streamlined the very start of the collection so we only compute the flags once per target.
This means #272 will be superseded by this one.
I have one minor nit about looping over all SOURCE_ATTR labels; otherwise LGTM!

Comment thread src/compile_commands.bzl Outdated
Comment on lines +133 to +146
compilation_deps = []
for attr in SOURCE_ATTR:
if hasattr(ctx.rule.attr, attr):
deps = getattr(ctx.rule.attr, attr)
if type(deps) == "list":
for dep in deps:
if CcInfo in dep:
compilation_deps.append(dep)
deps_flags = []
for dep in compilation_deps:
for flag in get_compile_flags(dep):
if flag not in deps_flags:
deps_flags.append(flag)
return deps_flags

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bazel already propagates flags for every SOURCE_ATTR type except implementation_deps (that's the point of implementation_deps). We don't need to loop over every attribute, only implementation_deps.
See my changes: https://github.com/Ericsson/rules_codechecker/pull/272/changes#diff-057ef75766b6e979efc7e1e8a4fc41ce228ae8465ee228e8d45c6d66983dcb94R147.

Something like this suggestion should work correctly:

Suggested change
compilation_deps = []
for attr in SOURCE_ATTR:
if hasattr(ctx.rule.attr, attr):
deps = getattr(ctx.rule.attr, attr)
if type(deps) == "list":
for dep in deps:
if CcInfo in dep:
compilation_deps.append(dep)
deps_flags = []
for dep in compilation_deps:
for flag in get_compile_flags(dep):
if flag not in deps_flags:
deps_flags.append(flag)
return deps_flags
# implementation_deps intentionally does not propagate its includes
# into the target's CcInfo.compilation_context, so we must extract
# them explicitly. This may produce duplication.
if not hasattr(ctx.rule.attr, "implementation_deps"):
return []
impl_deps = getattr(ctx.rule.attr, "implementation_deps")
if type(impl_deps) != "list":
return []
deps_flags = []
for dep in impl_deps:
if CcInfo not in dep:
continue
for flag in get_compile_flags(dep):
if flag not in deps_flags:
deps_flags.append(flag)
return deps_flags

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right, this "implementation_deps" is a strange thing.
To be honest I still dont understand how it works and what is the difference in dependencies.
I will take deeper look.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@nettle
nettle force-pushed the implementation-deps branch from 40405e5 to e92ad81 Compare August 25, 2026 16:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants