Instruction file imported from dds-bridge/dds (
.github/instructions/bazel.instructions.md). Copyright stays with the author.
Tip: Whenever you edit a BUIL or .bzl file, run a
bazelMCP command first to catch syntax or dependency issues.
Build Guidelines
| Rule | What it means | Why it matters |
|---|---|---|
| Explicit deps | List every dependency in deps = [...] |
Prevents hidden transitive pulls |
| No wildcards | Avoid glob([...]) unless absolutely needed |
Keeps target graph deterministic |
| Target naming | <component>_<purpose>_<type> |
Easier to read & search |
| Idiomatic Starlark | Prefer built-in rules over custom macros | Reduces maintenance |
| Consistent formatting | Follow .bazelrc & .bzlformat |
Keeps codebase uniform |
Best Practices
- Use
cc_library,cc_binary,cc_testfor C++ targets. - Keep test suites small & fast.
- Restrict visibility (
visibility = ["//visibility:private"]) when appropriate. - Run
bazelisk build //...&bazelisk test //...locally before pushing. - Document any non-trivial macros or build logic in comments.
Working with bazel commands
# Validate a BUILD file
bazel validate //path/to:BUILD
# Query dependencies of a target
bazel deps //my:target
# Generate a build command for a target
bazelisk build //my:target