bazel: plain bazel_deps from BCR, no host tools

[oharboe]

Makes naja's Bazel build idiomatic, Bazel all the way down, so it can become a Bazel Central Registry module: MODULE.bazel is now only bazel_deps, using upstream BCR modules, nothing is probed on the host, and naja builds both as the root module and as a dependency (verified from kepler-formal on Bazel 8.6 with hermetic-llvm, and on Bazel 9.2).

Ready to merge once CI is green. Bazel-only change.

BCR pull requests, for now. Modules not on BCR yet come from their BCR pull requests, pinned by commit in .bazelrc, until those merge. Each .bazelrc line is replaced by the proper BCR module as it lands. Meanwhile, a root MODULE.bazel project depending on this one has to carry the same .bazelrc registry lines.

Dependencies

Before	After
slang: built via rules_foreign_cc	sv-lang (native Bazel build)
TBB: pkg-config wrapper around the system lib	BCR onetbb
Boost: vendored tarball	BCR boost.intrusive, boost.dynamic_bitset, boost.asio, boost.multiprecision
fmt, tomlplusplus: git_repository + overlays	BCR fmt (tomlplusplus came only with slang)
spdlog: thirdparty/spdlog-1.17.0	BCR spdlog
bison/m4: found on PATH	BCR bison (bison rule)
Python: python3-config/PATH probing	rules_python toolchain (current_py_cc_headers/libs, $(PYTHON3_ROOTPATH))
cpptrace: git_override	dropped, unused by the Bazel build
naja_git_version/naja_workspace_root repository rules	git hash from the module version; SV tests resolve paths before chdir

Modules not on BCR yet

Each comes from its own BCR pull request, which .bazelrc lists by commit ahead of BCR; drop a line as its PR merges. There's no in-tree registry.

• naja-if, naja-verilog (naja-if@0.0.0-20260723-099677d9 bazelbuild/bazel-central-registry#10881, #10885): new modules. naja-verilog uses BCR bison/flex instead of host tools.
• sv-lang 11.0.0-20260701-b60d729d.bcr.1 (#10882): slang at b60d729 (BCR has f04e815, which doesn't compile against fmt 12.2). SLANG_STATIC_DEFINE, as upstream sets for static builds, which gcc 11 needs.
• bison 3.8.2.bcr.10 (#10879): gnulib's wrapper headers on -I instead of -isystem, for toolchains that pass libc headers as -isystem (hermetic-llvm).

ci/check_submodule_bazel_sync.py reads the pins from those registries.

.bcr/ holds publish-to-bcr templates for naja itself. naja, naja-if and naja-verilog list @xtofalex and @nanocoh as BCR maintainers.

Other fixes found while consuming naja from kepler-formal

• naja_runtime exports TBB/zlib, so binaries linking it don't link a second copy.
• pyloader re-owns libpython (python_libs.bzl). current_py_cc_libs neither advertises CcInfo nor owns its linker inputs, so cc_shared_library filtering silently dropped libpython from binaries that link naja_runtime dynamically.
• Explicit load()s for cc_*/sh_* (Bazel 9).
• FF_scan.lib exported for downstream test suites.

Testing

• bazel test //...: 20/20 pass (Bazel 8.6, host toolchain).
• kepler-formal's bazel test //... (hermetic-llvm), and its consumer smoke test on Bazel 9.2, pass with this branch merged with Do not infer a memory for an array written from several always blocks #455.
• bazel test //... in an ubuntu:22.04 container (gcc 11.4): 20/20 pass.
• Bazel CI workflows no longer install any packages.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.20%. Comparing base (927b9ca) to head (114804c).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #457      +/-   ##
==========================================
- Coverage   97.26%   97.20%   -0.06%     
==========================================
  Files         246      237       -9     
  Lines       45106    43348    -1758     
==========================================
- Hits        43871    42136    -1735     
+ Misses       1235     1212      -23     

Flag	Coverage Δ
unittests	97.20% <ø> (-0.06%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[xtofalex]

Hi @oharboe ,
For my understanding, how further releases of naja will be managed related to BCR. What is the triggering mechanism to upload new version there. Currently for uploading new najaeda package we trigger on git tags.
Also a question: shouldn't the downstream repos: naja-verilog and naja-if BCR management be managed from the repos themselves.
About versioning, i think we should have a unique naja versioning scheme following the one that is used also for the najaeda package, which serves as global versioning and that is stored in NajaVersion.h.in .

[oharboe]

how further releases of naja will be managed related to BCR. What is the triggering mechanism

There's no trigger, and none is needed. BCR versions don't have to follow naja releases or tags. A new BCR version is needed only when the Bazel files in the entry (the "overlay") have to change, for example when naja's build changes in a way the existing entry can't handle. That takes a person: someone edits the overlay, usually guiding an AI, checks it builds, and opens a BCR PR. As a listed maintainer, you approve that PR after BCR's CI has built it.

I'd advise against automatic BCR updates: they can't make the overlay changes that are the real reason to update. The .bcr/ templates in this PR are only a convenience for when you do want to publish a version. CMake and the pip/PyPI wheels are untouched by any of this.

As long as the existing entry still works with newer code, users don't need a new BCR version. They point their own build at a newer naja commit, or carry a patch.

shouldn't naja-verilog and naja-if BCR management be managed from the repos themselves

Yes, eventually. For now I've submitted them by hand, one BCR PR per module (bazelbuild/bazel-central-registry#10881 naja-if, bazelbuild/bazel-central-registry#10885 naja-verilog), at the commits naja uses, with commit-based versions. Once they're on BCR, the repos can take over.

a unique naja versioning scheme following the one used for the najaeda package, stored in NajaVersion.h.in

Agreed. MODULE.bazel already says version = "0.7.26", the same as NajaVersion.h.in, and a BCR entry for a naja version uses that version.

About urgency. With Bazel, something broken upstream is rarely urgent for a user:

• They can point their own build at a newer commit, or at a BCR PR that hasn't merged yet; this PR does exactly that in .bazelrc while its BCR PRs wait.
• They can carry a patch, and send it upstream if it's generally useful.
• Any non-trivial project carries a few upstream patches anyway; that's normal, not an emergency.

So being a maintainer mostly means approving a BCR PR now and then; nothing is on your critical path.

[oharboe]

@nanocoh @xtofalex Why did CI cancel builds? This is ready to merge if it goes green.

[xtofalex]

@nanocoh @xtofalex Why did CI cancel builds? This is ready to merge if it goes green.

Happens sometimes with network issue when a github runner is not able to download a dependency. Others associated jobs (here wheels) get cancelled. I've relaunched them.