CommonsBase_Dk 0.1.20260814140337

Packages the dk0 reference build system and dk1 multithreaded build system.

CommonsBase_Dk builds dk0 (MlFront's DkZero_Exec) as a per-package, content-addressed, resumable closure. A checked-in opam lock drives Dk0.Closure, which run-functions the generic CommonsLang_OCaml.Dk.OpamBuild rule for every package in DkZero_Exec's dependency closure so each package is its own cached dk object; an interrupted build resumes from the completed objects. The thin Dk0 recipe then republishes DkZero_Exec's install prefix as bin/dk0.exe. The shared MlFront source is fetched from a URL bundle and localized into Dk0.MlFrontSource (opam/dune metadata regenerated). Dk1 is wired to build the multi-threaded DkOne_Exec (dk1) the same way.

How a released dk0/dk1 is built, from an MlFront tag to a user's install. Every node names the file that implements it. V4 is the 4-part MlFront source version (for example 2.4.2.310); DRV is the pinned driver version -- the previous release's dk0/dk1 that runs this build.

Version overlay: V4 rides the git tag, then the zip's top directory name, then the RawSrc pin, then the localize stamp, then the manifest version= line. The binary's --version output is a compile-time constant generated once, inside the closure build, by MlFront's getver reading the stamped dune-project.template -- nothing after that step can change it. DRV appears only in the DK0_BASE_URL/DK1_BASE_URL driver pins and in the producer.application provenance metadata of the published stores: that metadata names the dk0 that RAN the build (by design), so a rev-<N-1> there is correct provenance, not the product version.

Dk0.Closure and Dk1.Closure are generated by the CommonsLang_OCaml.Dk.OpamLock.GenerateDriver dialog from the opam lock that Dk0.MlFrontSource carries (mlfront/dk.opam-lock.jsonc). Regenerate them rather than hand-editing whenever the lock changes or the per-package build rule version moves. There is no import partition here: CommonsBase_Dk builds every package in the closure as its own Dk0.Pkg/Dk1.Pkg object, so the driver passes no skiplocal/mergedprefix/implib arguments (unlike MlFront's TestDeps). <DRIVER_VER> is the GenerateDriver version from the pinned CommonsLang_OCaml import; the two invocations differ only in out, formid, pkgpath, and roots[]:

dk0 dialog CommonsLang_OCaml.Dk.OpamLock.GenerateDriver@<DRIVER_VER> lock=<dk-opam-lock.jsonc from Dk0.MlFrontSource> out=etc/dk/v/CommonsBase_Dk/Dk0.Closure.values.jsonc formid=CommonsBase_Dk.Dk0.Closure@2.4.2 pkgpath=CommonsBase_Dk.Dk0.Pkg version=2.4.2 rulefn=CommonsLang_OCaml.Dk.OpamBuild.F_BuildLockedPackage@1.0.15 localsrc=CommonsBase_Dk.Dk0.MlFrontSource@2.4.2 locksrcpath=./dk-opam-lock.jsonc roots[]=DkZero_Exec

dk0 dialog CommonsLang_OCaml.Dk.OpamLock.GenerateDriver@<DRIVER_VER> lock=<dk-opam-lock.jsonc from Dk0.MlFrontSource> out=etc/dk/v/CommonsBase_Dk/Dk1.Closure.values.jsonc formid=CommonsBase_Dk.Dk1.Closure@2.4.2 pkgpath=CommonsBase_Dk.Dk1.Pkg version=2.4.2 rulefn=CommonsLang_OCaml.Dk.OpamBuild.F_BuildLockedPackage@1.0.15 localsrc=CommonsBase_Dk.Dk0.MlFrontSource@2.4.2 locksrcpath=./dk-opam-lock.jsonc roots[]=DkOne_Exec

rulefn is the only field that moves when the per-package build rule is bumped (F_BuildLockedPackage@1.0.0 to @1.0.10 carried the Windows ocamlbuild fixes). For a rule-version-only bump the regenerated output differs from the committed driver in exactly that string, so a targeted rulefn replacement equals a full regeneration and avoids reformatting drift from a newer GenerateDriver.

Dk0 executable

  $ get-object CommonsBase_Dk.Dk0@2.4.2 -s Release.Darwin_arm64 -m ./bin/dk0.exe -f ${RUNTIME}/Darwin_arm64-dk0.exe
  \test(pass)
  \dk.object(abi: "Release.Darwin_arm64", value-id: "ojntwvxhhffbbyczw2n6dr5eeb5phjtr6bbqe7frctoyaz5byds5a")\;

  $ get-object CommonsBase_Dk.Dk0@2.4.2 -s Release.Darwin_x86_64 -m ./bin/dk0.exe -f ${RUNTIME}/Darwin_x86_64-dk0.exe
  \test(pass)
  \dk.object(abi: "Release.Darwin_x86_64", value-id: "opuhiyqk7pldho245lt673vm6mjhzts27neku5tfia6cpfq3vif7q")\;

  $ get-object CommonsBase_Dk.Dk0@2.4.2 -s Release.Linux_x86 -m ./bin/dk0.exe -f ${RUNTIME}/Linux_x86-dk0.exe
  \test(pass)
  \dk.object(abi: "Release.Linux_x86", value-id: "ojwkvwzp7b4tfaks6mihcz5ztyled4rvb5xlezjoeoibh6gkjgo7q")\;

  $ get-object CommonsBase_Dk.Dk0@2.4.2 -s Release.Linux_x86_64 -m ./bin/dk0.exe -f ${RUNTIME}/Linux_x86_64-dk0.exe
  \test(pass)
  \dk.object(abi: "Release.Linux_x86_64", value-id: "ojnw46bilxdfbbay4x4f6wbe4md55sfj5vrg7ssk25y722n7tjapq")\;

  $ get-object CommonsBase_Dk.Dk0@2.4.2 -s Release.Windows_x86 -m ./bin/dk0.exe -f ${RUNTIME}/Windows_x86-dk0.exe
  \test(pass)
  \dk.object(abi: "Release.Windows_x86", value-id: "oslr7wzrh6iudyj6vrrcosxpr7f74xzammw53dgsi64w5htqsb3rq")\;

  $ get-object CommonsBase_Dk.Dk0@2.4.2 -s Release.Windows_x86_64 -m ./bin/dk0.exe -f ${RUNTIME}/Windows_x86_64-dk0.exe
  \test(pass)
  \dk.object(abi: "Release.Windows_x86_64", value-id: "o7gc67phnxmcpcabywbcxg6jjdja2nyuvspowdxvi4z4qfw3vmzja")\;

Dk1 executable

  $ get-object CommonsBase_Dk.Dk1@2.4.2 -s Release.Darwin_arm64 -m ./bin/dk1.exe -f ${RUNTIME}/Darwin_arm64-dk1.exe
  \test(pass)
  \dk.object(abi: "Release.Darwin_arm64", value-id: "ospnonf7b7n2dqd6ul7fcr6ktfl55n5tlvivpkmrkgtdzxtr3uqqq")\;

  $ get-object CommonsBase_Dk.Dk1@2.4.2 -s Release.Darwin_x86_64 -m ./bin/dk1.exe -f ${RUNTIME}/Darwin_x86_64-dk1.exe
  \test(pass)
  \dk.object(abi: "Release.Darwin_x86_64", value-id: "og7fhndqrm3vo7ahdyqknvbddoigcnklmyqimrerdzshqef6ftqxq")\;

  $ get-object CommonsBase_Dk.Dk1@2.4.2 -s Release.Linux_x86 -m ./bin/dk1.exe -f ${RUNTIME}/Linux_x86-dk1.exe
  \test(pass)
  \dk.object(abi: "Release.Linux_x86", value-id: "ogfgbyjziz6c52kgrktgma2yr364kzrl4pjtk6ptoljcrpgo5frwa")\;

  $ get-object CommonsBase_Dk.Dk1@2.4.2 -s Release.Linux_x86_64 -m ./bin/dk1.exe -f ${RUNTIME}/Linux_x86_64-dk1.exe
  \test(pass)
  \dk.object(abi: "Release.Linux_x86_64", value-id: "ocugsqb254bl2dshjuw4wikomf2lypacjjyv4luqtjscpoyxrhm4a")\;

  $ get-object CommonsBase_Dk.Dk1@2.4.2 -s Release.Windows_x86 -m ./bin/dk1.exe -f ${RUNTIME}/Windows_x86-dk1.exe
  \test(pass)
  \dk.object(abi: "Release.Windows_x86", value-id: "o4auic5ia6clasktaibqmgt6ycn5i5aw5lqx7pc4otaqsuujsfkeq")\;

  $ get-object CommonsBase_Dk.Dk1@2.4.2 -s Release.Windows_x86_64 -m ./bin/dk1.exe -f ${RUNTIME}/Windows_x86_64-dk1.exe
  \test(pass)
  \dk.object(abi: "Release.Windows_x86_64", value-id: "o3ltgg5f5wymy65idfqxyd7dhljmdtuaownktnawvncctaxqc7rra")\;

CommonsBase_Dk distribution

`CommonsBase_Dk` ships the `dk0` (MlFront `DkZero_Exec`) and `dk1` (`DkOne_Exec`)
build-system executables. Each is built from source as a per-package,
content-addressed opam closure (`CommonsBase_Dk.Dk0.Closure` /
`CommonsBase_Dk.Dk1.Closure`) and republished as a single native executable per
slot:

- `CommonsBase_Dk.Dk0@2.4.2` -> `bin/dk0.exe`
- `CommonsBase_Dk.Dk1@2.4.2` -> `bin/dk1.exe`

The executable slots are `Linux_x86_64`, `Linux_x86`, `Darwin_x86_64`,
`Darwin_arm64`, `Windows_x86_64`, and `Windows_x86`. Each slot's distribution
script (`dist/<slot>.u`) `get-object`s the `bin/dk0.exe` and `bin/dk1.exe`
members for that slot. `Linux_x86_64_musl` was retired (2026-08-12): its
musl-linked host tools collided with the glibc `Linux_x86_64` slot at combine,
and proper musl support is blocked on CommonsLang_OCaml issues #2/#3; Linux
consumers use the manylinux (glibc) container until then. `Windows_arm64` is
not shipped: there is no DkML arm64 toolchain slice yet.