dk packages /

CommonsBase_Dk 0.1.20260821192936

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

Apache-2.0 AND LGPL-2.1-only WITH OCaml-LGPL-linking-exception AND OSL-3.0 Source → Generated

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.

Data flow

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.

MlFront metadata-release (manual pipeline, DK_GH_TAG)

CommonsBase_Dk (this repo; GitHub Actions on tag 0.1.TS)

MlFront GitLab (dkml/build-tools/MlFront tag pipeline)

url+sha256 pin: etc/dk/v/CommonsBase_Dk/Dk0Localize.RawSrc.values.jsonc

the dk-dist/V4 manifest becomes the NEXT release's DK0_BASE_URL driver pin: driver version N-1 builds product version N

store: none. The repin-invalidation hole (a store: release restore served the PREVIOUS release's objects after a source repin: rev-309-under-2.4.2.310, rev-312-under-2.4.2.313) is FIXED in the 2.4.2.317 driver (2.4.2.315 lazy-dependency evidence + 2.4.2.317 D3 locality escape). But store: release is NOT VIABLE here on performance: a source-version repin changes the universal Dk0.MlFrontSource, invalidating the whole &@2.4.2 closure, so a correct store: release rebuilds ~everything AND pays per-object restore/lazy-force overhead -- the 2.4.2.318 proof ran the full 6h job limit without finishing vs ~35min for a store: none cold build. Keep store: none until the restore path is made performant for a full-closure invalidation

git tag V4, gitsign-signed

publish-source: gitsign verify, then ci/publish-source-zip.sh

mlfront-source/V4/MlFront-V4.zip -- V4 encoded in the top directory name

Dk0Localize.RawSrc&@2.4.2

Dk0.MlFrontSource&@2.4.2: assets/dk0/localize.sh derives V4 from the directory name, stamps ci/version.source.sh + dune-project.template, runs localize-pristine; emits the mlfront/ tree + dk-opam-lock.jsonc

Dk0.Closure&@2.4.2 / Dk1.Closure&@2.4.2: one CommonsLang_OCaml.Dk.OpamBuild.F_BuildLockedPackage run per locked package; toolchain objects DkML, Dune, MSYS2, VSWhere; the binary's --version constant is baked here when dune builds DkZero_Exec/DkOne_Exec from the stamped tree

Dk0&@2.4.2 / Dk1&@2.4.2: extract the root package install.zip, republish bin/dk0.exe per slot

distribute matrix: .github/workflows/distribute-0.1.yml, one dist/<slot>.u per ABI; driver pinned by DK0_BASE_URL/DK1_BASE_URL = dk-dist/DRV

distribution-<part> artifacts + flat dk-dist/dk{0,1}-<abi> staged by publish-objects

combine job: jsign Authenticode (Windows), rcodesign Developer ID (macOS), SLSA attest, gh-release under tag 0.1.TS

ci/verify-github-release.sh: SLSA attestation + OS code signatures + gitsign source signature, fail-closed

ci/gen-manifest.sh: version=V4, dk0_url_template to the 0.1.TS release, per-ABI sha256; ci/sign-release.sh signify-signs

dk-dist/V4 generic package: manifest.txt + .sig + signed install.ps1/vendor.ps1

verify-install:<abi> smoke jobs: install and assert dk0 --version == 2.4.2+rev-N

launchers + install.sh/install.ps1: signify-verify the manifest, fetch by dk0_url_template

users

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.

Regenerating the Closure drivers

Dk0.Closure, Dk1.Closure, and TestPkg.Closure are generated by the CommonsLang_OCaml.Dk.OpamLock.GenerateDriver dialog from the opam lock that Dk0.MlFrontSource carries (mlfront/dk.opam-lock.jsonc, and the with-test dk-opam-lock-test.jsonc). Since Dk.OpamLock@1.1.8 each driver stamps its parameters into a top-level generated member, so a routine bump of the per-package build rule is a Refresh, not a hand-edit. mode=check compares each driver's stamped rule versions against the pinned CommonsLang_OCaml import and fails with the fix command when one is stale; it runs in distribute-0.1.yml before the build:

dk0 dialog CommonsLang_OCaml.Dk.OpamLock.Refresh@1.1.8 mode=check drivers[]=etc/dk/v/CommonsBase_Dk/Dk0.Closure.values.jsonc drivers[]=etc/dk/v/CommonsBase_Dk/Dk1.Closure.values.jsonc drivers[]=etc/dk/v/CommonsBase_Dk/TestPkg.Closure.values.jsonc

The lock lives inside Dk0.MlFrontSource/TestPkg.LockSrc and is not checked in, so the default Refresh (drop mode=check) rewrites the rulefn in place, which equals a full regeneration for a rule-version-only move and avoids reformatting drift from a newer GenerateDriver. A change to the lock CONTENT (not just the rule version) needs a full regeneration with the lock materialized from its source object. <DRIVER_VER> is the GenerateDriver version from the import; Dk1 differs only in out, formid, pkgpath, and roots[]=DkOne_Exec:

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.18 localsrc=CommonsBase_Dk.Dk0.MlFrontSource@2.4.2 locksrcpath=./dk-opam-lock.jsonc roots[]=DkZero_Exec

TestPkg.Closure builds the MlFront --with-test external closure (astring, tezt, crowbar, sedlex, ...) as one merged-prefix object so the gate imports it instead of building that closure cold. It uses the test lock, skiplocal=t, mergedprefix=t, an import partition against Dk0.Pkg, and its own TestPkg.LockSrc source:

dk0 dialog CommonsLang_OCaml.Dk.OpamLock.GenerateDriver@<DRIVER_VER> lock=<dk-opam-lock-test.jsonc from Dk0.MlFrontSource> out=etc/dk/v/CommonsBase_Dk/TestPkg.Closure.values.jsonc skiplocal=t mergedprefix=t formid=CommonsBase_Dk.TestPkg@2.4.2 pkgpath=CommonsBase_Dk.TestPkg.Pkg version=2.4.2 rulefn=CommonsLang_OCaml.Dk.OpamBuild.F_BuildLockedPackage@1.0.18 localsrc=CommonsBase_Dk.TestPkg.LockSrc@2.4.2 locksrcpath=./dk-opam-lock-test.jsonc implib[]=CommonsBase_Dk.Dk0.Pkg impver[]=2.4.2 impsrclock[]=dk.opam-lock.jsonc roots[]=DkZero_Exec roots[]=DkOne_Exec ... (the same roots as the gate's TestDeps)

dist/Linux_x86_64.u and dist/Windows_x86_64.u get-object the TestPkg object so it is built and published for the gate to import (Darwin slots pending the M4 macOS gate).

Usage

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")\;

TestPkg (with-test external closure, imported by the MlFront test gate)

  $ get-object CommonsBase_Dk.TestPkg@2.4.2 -s Release.Darwin_arm64 -m ./prefix.zip -d ./testpkg
  \test(pass)
  \dk.object(abi: "Release.Darwin_arm64", value-id: "ovoqeizl3j5mkt2yav2dmor7anankbjg6astvqizcjtbundx5ufja")\;
  $ get-object CommonsBase_Dk.TestPkg@2.4.2 -s Release.Darwin_x86_64 -m ./prefix.zip -d ./testpkg
  \test(pass)
  \dk.object(abi: "Release.Darwin_x86_64", value-id: "o2iomxc4rrrrz2k4na4vbfpw2ps4eafullo3dowlme353e6j4hmsq")\;
  $ get-object CommonsBase_Dk.TestPkg@2.4.2 -s Release.Linux_x86_64 -m ./prefix.zip -d ./testpkg
  \test(pass)
  \dk.object(abi: "Release.Linux_x86_64", value-id: "ovkwj67odprf3yfjc4ap4pqr4vls3li6pv3w5gl5onjowuqbdl3yq")\;
  $ get-object CommonsBase_Dk.TestPkg@2.4.2 -s Release.Windows_x86_64 -m ./prefix.zip -d ./testpkg
  \test(pass)
  \dk.object(abi: "Release.Windows_x86_64", value-id: "o6x543fsnoaechmldejlzv6trawtj47lmjcp7egkoxmi4cmksvrsq")\;

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.

Provides

ModuleVersionPlatformvalue-id
CommonsBase_Dk.Dk0 2.4.2 Darwin_arm64 ojntwvxhhffb…
CommonsBase_Dk.Dk0 2.4.2 Darwin_x86_64 opuhiyqk7pld…
CommonsBase_Dk.Dk0 2.4.2 Linux_x86 ojwkvwzp7b4t…
CommonsBase_Dk.Dk0 2.4.2 Linux_x86_64 ojnw46bilxdf…
CommonsBase_Dk.Dk0 2.4.2 Windows_x86 oslr7wzrh6iu…
CommonsBase_Dk.Dk0 2.4.2 Windows_x86_64 o7gc67phnxmc…
CommonsBase_Dk.Dk1 2.4.2 Darwin_arm64 ospnonf7b7n2…
CommonsBase_Dk.Dk1 2.4.2 Darwin_x86_64 og7fhndqrm3v…
CommonsBase_Dk.Dk1 2.4.2 Linux_x86 ogfgbyjziz6c…
CommonsBase_Dk.Dk1 2.4.2 Linux_x86_64 ocugsqb254bl…
CommonsBase_Dk.Dk1 2.4.2 Windows_x86 o4auic5ia6cl…
CommonsBase_Dk.Dk1 2.4.2 Windows_x86_64 o3ltgg5f5wym…
CommonsBase_Dk.TestPkg 2.4.2 Darwin_arm64 ovoqeizl3j5m…
CommonsBase_Dk.TestPkg 2.4.2 Darwin_x86_64 o2iomxc4rrrr…
CommonsBase_Dk.TestPkg 2.4.2 Linux_x86_64 ovkwj67odprf…
CommonsBase_Dk.TestPkg 2.4.2 Windows_x86_64 o6x543fsnoae…

Workspace assets

Files and directories in the package repo, bundled into the build.

AssetProject pathType
Dk0BuildWin assets/dk0/dk0-build-win.bat file
Script assets/dk0/localize.sh file

Dependencies

PackageVersionsha256
CommonsBase_Std 2.6.20260813134421 f932d71bd74c858f…
CommonsBase_Build 0.1.20260718232516 f48d91a5fad0af89…
CommonsBase_GNU 0.1.20260803042217 e4e77c1e3e625835…
CommonsLang_OCaml 0.1.20260821175730 7457549cedb00ed9…

Producer signing key

Releases of this package are signed with this OpenBSD signify key. After you import the package, dk1 trust list prints the same public key and fingerprint; compare them here to confirm you are trusting the intended publisher over a channel independent of the download.

Fingerprint 7457b62e3a48e8c0
Public key RWR0V7YuOkjowOzjI9eRXrpE3XR6Wfky2AEfyAZ89inqlL05eZ06U+JM