Skip to content

refactor: follow the cl-prolog-kit / cl-dataflow-kit rename - #2

Open
takeokunn wants to merge 4 commits into
mainfrom
feat/rename-cl-prolog-dataflow-kit
Open

refactor: follow the cl-prolog-kit / cl-dataflow-kit rename#2
takeokunn wants to merge 4 commits into
mainfrom
feat/rename-cl-prolog-dataflow-kit

Conversation

@takeokunn

Copy link
Copy Markdown
Contributor

nerima-lisp/cl-prolog was renamed to cl-prolog-kit (v1.5.0) and cl-dataflow to cl-dataflow-kit (v1.2.0). The ASDF system names and CL package names moved with the repositories, so cl-prolog: no longer resolves and :depends-on "cl-prolog" no longer finds a system.

Updated: the flake input's Nix variable name and URL, the ASDF :depends-on entries, every package-qualified symbol reference, and prose naming either package. flake.lock was regenerated with nix flake lock, never hand-edited.

The pin also moves forward to the current release rather than carrying the old one — the tag the old pin named no longer contains a system under the old name.

Verification before pushing: a residual grep for cl-prolog/cl-dataflow not followed by -kit (and the uppercase and CL_…_ env-var spellings) returns zero hits, no kit-kit double suffix was produced, and (/) counts are byte-identical per .lisp/.asd file before and after — so the source change is rename-only. CI here is the build verification.

nerima-lisp/cl-prolog was renamed to cl-prolog-kit (v1.5.0) and
cl-dataflow to cl-dataflow-kit (v1.2.0). The ASDF system names and CL
package names moved with the repositories, so `cl-prolog:` no longer
resolves and `:depends-on "cl-prolog"` no longer finds a system.

Updated here: the flake input's Nix variable name and URL, the ASDF
:depends-on entries, every package-qualified symbol reference, and the
prose that names either package. flake.lock was regenerated with
`nix flake lock`, not hand-edited.

This also moves the pin forward to the current release rather than
carrying the old one, since the tag the old pin named no longer contains
a system under the old name.
The cl-cc revision pinned here predates cl-cc's rename migration, so the
sibling sources it brings into CL_SOURCE_REGISTRY still declared
:depends-on (... :cl-prolog ...). ASDF resolves system names across the
whole registry, so one stale tree was enough to fail the build with

  Component :CL-PROLOG not found

even though this repository's own sources had already been migrated. An
aggregating repository cannot move to the -kit names until every tree it
aggregates has moved; that ordering constraint lives at the ASDF layer,
so nothing in the flake input graph expresses it.

Pinned to cl-cc's current main, which carries the migration. A raw
revision was already the form used here.
…ources

cl-cc-javascript/test declared :depends-on (:cl-cc ...). cl-cc's own
:depends-on ends in (... :cl-cc-php :cl-cc-javascript), so that pulled
this very system in through the umbrella as well as directly, plus
cl-cc-php, -selfhost, -repl, -cli and every other sibling frontend the
umbrella carries -- none of which this suite touches.

cl-cc-php.asd sets the precedent: its /test system deliberately depends
on :cl-cc-pipeline rather than :cl-cc, its comment saying that folding
the umbrella in "would make every consumer of the PHP frontend drag
along codegen/optimize/regalloc/emit for no reason". Same reasoning
here, minus the self-reference cl-cc-php does not have to worry about.

The 15 new flake inputs are cl-cc-pipeline's real transitive closure,
traced by reading every .asd on origin/main rather than assumed: 12
standalone cl-cc-* repositories plus cl-regex-kit (via cl-cc-vm),
cl-process-kit (via cl-cc-runtime and -binary) and cl-codec-kit (via
cl-process-kit). cl-cc.asd states these live in standalone repositories
and "reach this build as flake.nix inputs", so a consumer that
materialises cl-cc's source tree has to supply every one of them.

Two details that are not guessable from the input list:
  - cl-cc-codegen-native holds cl-cc-codegen, cl-cc-emit and
    cl-cc-regalloc in subdirectories, and dependency-roots.lisp's
    registry entries are non-recursive :directory scans -- so that one
    input gets three ROOT variables pointing at subpaths of it, not
    three inputs.
  - cl-cc-vm, cl-cc-expand, cl-cc-runtime and cl-process-kit are pinned
    to main rather than their newest tag: each tag predates a
    cl-host-kit/cl-concurrent-kit dependency still on main.

NOT VERIFIED LOCALLY. GitHub returned 429/502/503 for the tarball of
every new input, with Nix's backoff climbing past eight minutes per
retry, so `nix flake check` could not complete here. CI is the first
real verification; this must not merge until it is green. The count to
check against is 1351 tests -- the last green run on main (2026-08-01,
run 30695692132, sha 777d545) logged 1351 passed, and no file under t/
has changed since.
cl-cc-bootstrap v0.1.0 is the release that removed
register-backend-parser, register-backend-bridge-provider and their six
siblings as "dead code never referenced anywhere in this repository" --
true of that repository, false of this one, which calls them at load
time from src/runtime-bridge-provider.lisp. Building against v0.1.0
therefore fails with

  no symbol named "REGISTER-BACKEND-PARSER" in "CL-CC/BOOTSTRAP"

cl-cc-bootstrap has since restored all eight, with tests, so this pins
its current main. That is a raw revision because the restoration
postdates v0.1.0 and no newer tag exists yet.
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