Skip to content

fix(build): regenerate communication bridge for header changes - #57

Open
voltjia wants to merge 1 commit into
masterfrom
fix/bridge-header-dependencies
Open

fix(build): regenerate communication bridge for header changes#57
voltjia wants to merge 1 commit into
masterfrom
fix/bridge-header-dependencies

Conversation

@voltjia

@voltjia voltjia commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Summary

Regenerate the generated communication bridge whenever a source header used by the bridge generator changes. Existing build directories could otherwise retain a stale backend manifest after provider headers were added, removed, or modified.

Changes

  • Dependency tracking
    • Track the base, backend, and device headers read by the bridge generator.
    • Generate a stable dependency list so header additions and removals trigger CMake reconfiguration.
    • Add the tracked headers to the bridge custom command dependencies.
  • Regression coverage
    • Add a source contract test for the generator dependency graph.
    • Register the contract with CTest.

Platform and Backend Affected

Platform

  • CPU
  • NVIDIA GPU
  • Iluvatar GPU
  • MetaX GPU
  • Moore Threads GPU
  • Cambricon MLU
  • HYGON DCU

Backend

  • OpenMPI
  • MPICH
  • NCCL
  • MCCL

Performance Impact

  • No performance impact
  • Performance improved
  • Performance regression possible

N/A. This changes build invalidation only.

Known Issues & Future Work

  • None.

Test Results

Test environment: ssh nvidia, accelerator-dev/nvidia:latest.

  • Clean OpenMPI configure and build passed.
  • Touching an existing provider header regenerated the manifest and bridge.
  • Adding a provider header triggered CMake glob reconfiguration, regenerated the bridge, and added the provider to the manifest.
  • CTest passed.
  • ruff check, ruff format --check, and git diff --check passed.

Test Involved Platform

  • CPU
  • NVIDIA GPU
  • Iluvatar GPU
  • MetaX GPU
  • Moore Threads GPU
  • Cambricon MLU
  • HYGON DCU

Test Involved Backend

  • OpenMPI
  • MPICH
  • NCCL
  • MCCL

Checklist

Title, Branch, and Commits

  • PR title follows Conventional Commits.
  • Branch name follows <type>/xxx-yyyy-zzzz.
  • Each commit message follows Conventional Commits.
  • This small PR is a single squashable commit.
  • No stray merge commits from master.
  • No fixup! / squash! / wip commits remain.

Scope and Design

  • Changes are minimal and contain no unrelated modifications.
  • No dead code, debug output, or unowned TODOs were added.
  • No unrelated formatting churn was introduced.
  • N/A: No public runtime API changes are included.

General Code Hygiene

  • Comments are limited to non-obvious intent.
  • Every modified or added file ends with a single trailing newline.
  • No trailing whitespace, inconsistent indentation, or mixed formatting remains.
  • Code identifiers in comments and errors use Markdown backticks where applicable.
  • Comments and error messages are in English.
  • Comments and error messages follow the repository language conventions.

C++ Specific

N/A: No C++ source file changes are included.

Python Specific

  • The regression test is PEP 8 compliant and ruff check passes.
  • ruff format --check passes.
  • Comments follow the repository conventions.
  • Framework-specific conventions are preserved.
  • Function body spacing follows the repository conventions.
  • Control-flow spacing follows the repository conventions.
  • Return statement spacing follows the repository conventions.
  • Docstrings follow PEP 257 where applicable.
  • Type hints are consistent with surrounding tests.

Testing

  • N/A: This build-dependency PR has no runtime example behavior; clean and incremental bridge builds are covered above.

Build, CI, and Tooling

  • N/A: No backend or device auto-detection entry is added.
  • The applicable Ruff checks pass locally; clang-format is not applicable.

Documentation

  • N/A: This fixes internal build invalidation and does not change the user workflow or public behavior.
  • N/A: No user-visible breaking change is introduced.

Security and Safety

  • No secrets, internal URLs, customer data, or personal hardware identifiers are included.
  • No third-party code is introduced.
  • No unsafe pointer arithmetic, uninitialized read, or bounds-check change is introduced.

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