Skip to content

Warn that Bazel's defines are transitive (for discussion) - #57

Open
anakanemison wants to merge 1 commit into
mschaller/d4-long-commandsfrom
mschaller/d5-transitive-defines
Open

anakanemison wants to merge 1 commit into
mschaller/d4-long-commandsfrom
mschaller/d5-transitive-defines

Conversation

@anakanemison

Copy link
Copy Markdown

Part 22 of 23 of a stacked series (tracking issue: #35). Based on D4-long-commands, the previous part: review and merge that first.

Kind: discussion. Lab proposal: P7.

What the migration runs showed

defines propagate to dependents where CMake's PRIVATE definitions do not. With the warning, the lensfun run kept <target>_EXPORTS and visibility defines in local_defines (run 083).

The change

CMake scopes a compile definition to a target (PRIVATE) or its consumers
(PUBLIC/INTERFACE). Bazel's defines always propagate to every dependent;
the equivalent of PRIVATE is local_defines. The per-TU diff only checks
that each TU gets the defines CMake gave it, so a PRIVATE define written as
defines converges while changing how every consumer compiles (a
visibility macro such as _EXPORTS turning on export-side behavior
in consumers is the classic case). The only signal would be a WARN-level
extra define on each consumer's TUs.

Observed in any2bazel-lab: a
lensfun migration avoided this unprompted, putting its visibility and
_EXPORTS defines in local_defines for exactly this reason. No run
has yet been seen getting it wrong, so there is no evidence the skill needs
the line.

Adds one sentence to "Create initial BUILD.bazel files". In the lab's later
lensfun run with this change, the agent again kept those defines in
local_defines.

This is a proposal for discussion: it costs a line of context in every run
to prevent a mistake not yet observed.

Testing

pytest tests/ at this commit: 196 passed (130 on main).

🤖 Generated with Claude Code

CMake scopes a compile definition to a target (PRIVATE) or its consumers
(PUBLIC/INTERFACE). Bazel's `defines` always propagate to every dependent;
the equivalent of PRIVATE is `local_defines`. The per-TU diff only checks
that each TU gets the defines CMake gave it, so a PRIVATE define written as
`defines` converges while changing how every consumer compiles (a
visibility macro such as <target>_EXPORTS turning on export-side behavior
in consumers is the classic case). The only signal would be a WARN-level
extra define on each consumer's TUs.

Observed in any2bazel-lab: a
lensfun migration avoided this unprompted, putting its visibility and
<target>_EXPORTS defines in local_defines for exactly this reason. No run
has yet been seen getting it wrong, so there is no evidence the skill needs
the line.

Adds one sentence to "Create initial BUILD.bazel files". In the lab's later
lensfun run with this change, the agent again kept those defines in
local_defines.

This is a proposal for discussion: it costs a line of context in every run
to prevent a mistake not yet observed.

Lab-Proposal: P7

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant