sigil

0.19.4

release

A build-integrity release. sigil build now checks, before it compiles anything, that your compiler and the runtime you have locked and installed are the same generation. -L also works for the first time on the modules the CLI loads at startup.

Download 0.19.4Get started

Existing projects build without changes. The coherence check ships in reporting mode: it prints what it finds and the build continues.

A build that cannot work says so before it compiles

A build whose compiler and whose locked runtime disagree used to exit 0. It printed "Build complete!" over an artifact that was dead on arrival, and one of those reached a phone.

That matters more than one bad binary, because every other verification you have ends in "it built". A toolchain that can emit a dead artifact and exit 0 means no green anywhere is worth anything.

Three checks now run first, each reading a different source so no two can fail together by construction: compiler identity against the lockfile, the lockfile against the .sigil/deps symlinks, and compiler identity against the headers on disk. That last one never reads sigil.lock, so hand-editing the lock does not get you past it. A fourth check confirms the sigil you resolved is at least the minimum each dependency asks for.

Why it reports instead of refusing

SIGIL_BUILD_COHERENCE takes report, enforce or off, and defaults to report.

That default is the design, not caution. Eleven of the estate's twelve consumer repos are incoherent today, so enforcing on day one means eleven teams discover that the only way to build is to switch the check off. A bypass that becomes a habit is worse than no check: it trains you to reach past the next one too.

Reporting prints one line per finding, detail under --verbose. The default flips to enforce when the estate can pass it, and both modes are gated on the same tree so flip day is not the first run of the code that matters.

-L and SIGIL_LIB now reach the modules the CLI loads first

sigil -L <dir> searched <dir> only for modules the runtime had not already loaded, which in practice exempted every module the CLI imports at startup. The consequence was concrete: an extracted package could not be tested from its own checkout. sigil test in sigil-log ran the binary's copy of (sigil log), and a syntax error appended to the checkout's source changed nothing.

The resolver was never at fault. -L was parsed only in Scheme, long after the CLI's module graph had been imported, and an already-registered module is returned before any load path is consulted. The defect was temporal, not ordinal. Both emitted entry points now scan argv before any Scheme import. Precedence, lowest first: @bundle/lib, <exe>/../lib, SIGIL_LIB, then -L.

Three problems in that change were caught in review and fixed here, two of which did not exist in 0.19.2: 128 -L flags hung forever with no output where 0.19.2 printed an error and exited 1; the argv scan reached bundled applications, so app -L <dir> could replace one of the app's own modules; and "leftmost -L wins" was false, because options were re-registered left to right after the C scan had registered them right to left.

One consequence worth stating plainly: because -L now outranks the embedded archive, a load path can overshadow modules the release binary ships with, including the ones behind registry signature checks. That is intended behavior going forward, and it is what makes an extracted package testable from its own checkout.

Also in this release

Upgrade notes

If your project is incoherent, sigil build will now say so on every build. The remedy is named in the message: run sigil deps install. A git pull that touched sigil.lock is enough to put you here.

Set SIGIL_BUILD_COHERENCE=off to silence it, or enforce to get the refusal now.