Skip to content

Keep "stop" only for build-time generation with no Bazel mapping (for discussion) #55

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
anakanemison wants to merge 1 commit into from
Open

Keep "stop" only for build-time generation with no Bazel mapping (for discussion) #55

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -243,8 +243,12 @@ proceed, unless an item on the not-yet-supported list below applies: without an
answer, stop there and report it.

**NOT yet supported — warn the user if the project has these:**
- Build-time custom commands / generated code. Configure-time generated
files are handled by you, not the tool: see the reference guide.
- Build-time generation with **no clear Bazel mapping**: a sub-build the
reference model does not show (autotools, a vendored fork's own build) whose
outputs the binaries link. Other codegen and configure-time generated files
are yours to migrate: see
[Create initial BUILD.bazel files](#create-build-files) and the reference
guide.
- Per-test-binary identity alignment, and include search **order** (presence
only) — both have planned follow-ups
- Packaging / install rules
Expand Down Expand Up @@ -301,6 +305,10 @@ silently: a genrule cannot see `.git` from the sandbox, and the binary reports
an "unknown version". Feed them through `--workspace_status_command` to a
`stamp = 1` rule.

**Build-time codegen** that maps to a `genrule` over a host tool (bison/flex) or
to a ruleset (protoc) is yours to migrate: use the project's declared generator
version.

The reference guide covers what is specific to translating its build system
(for CMake: the build type and configure-time generated files).

Expand Down
6 changes: 4 additions & 2 deletions docs/REFERENCE-cmake.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,8 +14,10 @@ as the reference build.

When [confirming scope](../SKILL.md#confirm-scope), inspect `CMakeLists.txt`
for these and surface them before proceeding:
- Build-time generated code: `add_custom_command`, protoc or other codegen
steps. `configure_file` is handled by you, not the tool: see
- Build-time generation with no clear Bazel mapping: a sub-build the CMake
model does not show (autotools, a vendored fork's own build) whose outputs
the binaries link. Other codegen (`add_custom_command`, protoc) is yours to
migrate, and so is `configure_file`: see
[Configure-time generated files](#configure-time-generated-files).
- `find_package` of non-system libraries. There is no automatic
`find_package` → bzlmod resolution; each one must be mapped by hand.
Expand Down
Loading