Repository navigation
Align executables by unambiguous label basename - #42
Open
anakanemison wants to merge 1 commit into
Open
anakanemison wants to merge 1 commit into
anakanemison wants to merge 1 commit into
Conversation
The CMake model keys executables by bare target name (BinRec), the Bazel model by package-qualified label (gems:BinRec). Executables align by exact name, so every executable in a non-root package needed a target_map entry even when nothing was renamed, which buries the entries that record real renames. Measured in any2bazel-lab: two graphicsgems migrations wrote 32 and 26 target_map entries, none of them a rename; every entry bridged a bare CMake name to its package-qualified Bazel label. After target_map is applied, each CMake executable that still has no exact-name counterpart aligns with the Bazel executable whose label basename equals its name, when exactly one unaligned Bazel executable has that basename. Two packages sharing the basename are left unaligned (missing_target plus extra_target, as before) for target_map to resolve; libraries, external-repo labels, and CMake names that are target_map keys (even when the mapped Bazel target does not exist) never align this way. The pairs are reported in diff.json as "aligned_by_basename" so the implicit matches stay reviewable. The alignment is part of _bazel_renames, the one rename decision the diff and every summary share, so an exclude_targets entry for an auto-aligned executable is honoured the same way by the comparison, the excluded list, the levels and the NDEBUG counts. SKILL.md now reserves target_map for renames and ambiguous basenames. In the lab's later graphicsgems run with this change, target_map was empty (the earlier run had 30 entries). Lab-Proposal: P3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Part 7 of 23 of a stacked series (tracking issue: #35). Based on
U06-say-what-convergence-covers, the previous part: review and merge that first.Kind: report. Lab proposal: P3.
What the migration runs showed
Every graphicsgems migration needed 30 to 32
target_mapentries, none of them a rename. With basename alignment,target_mapholds only real renames (082: 30 entries to 0).The change
The CMake model keys executables by bare target name (BinRec), the Bazel
model by package-qualified label (gems:BinRec). Executables align by exact
name, so every executable in a non-root package needed a target_map entry
even when nothing was renamed, which buries the entries that record real
renames.
Measured in any2bazel-lab: two graphicsgems migrations wrote 32 and 26
target_map entries, none of them a rename; every entry bridged a bare
CMake name to its package-qualified Bazel label.
After target_map is applied, each CMake executable that still has no
exact-name counterpart aligns with the Bazel executable whose label
basename equals its name, when exactly one unaligned Bazel executable has
that basename. Two packages sharing the basename are left unaligned
(missing_target plus extra_target, as before) for target_map to resolve;
libraries, external-repo labels, and CMake names that are target_map keys
(even when the mapped Bazel target does not exist) never align this way.
The pairs are reported in diff.json as "aligned_by_basename" so the
implicit matches stay reviewable. The alignment is part of _bazel_renames,
the one rename decision the diff and every summary share, so an
exclude_targets entry for an auto-aligned executable is honoured the same
way by the comparison, the excluded list, the levels and the NDEBUG
counts. SKILL.md now reserves target_map for renames and ambiguous
basenames.
In the lab's later graphicsgems run with this change, target_map was empty
(the earlier run had 30 entries).
Testing
pytest tests/at this commit: 186 passed (130 onmain).🤖 Generated with Claude Code