Skip to content

make precompileModules opt-in via precompile option - #47

Open
johnchandlerburnham wants to merge 1 commit into
mainfrom
configurable-precompile
Open

make precompileModules opt-in via precompile option#47
johnchandlerburnham wants to merge 1 commit into
mainfrom
configurable-precompile

Conversation

@johnchandlerburnham

@johnchandlerburnham johnchandlerburnham commented Aug 27, 2026

Copy link
Copy Markdown
Member

Consumers that call Blake3 inside #eval at elaboration time — e.g. Verso
blog posts with executable code examples — need the FFI symbols loaded into
the elaborating process, both in batch lake build and in language-server
file workers. Without that, the interpreter fails with Could not find native implementation of external declaration 'Blake3.C.hasherInit', and there is
no reliable way to fix this purely from the consumer side (--load-dynlib
via moreGlobalServerArgs crash-loops LSP workers, and module-level dynlibs
don't bundle moreLinkObjs objects).

Lake's mechanism for this is precompileModules: the lib's shared library —
which does bundle the moreLinkObjs native objects — is built and
automatically loaded for importers, in batch builds via injected
--load-dynlib and in the language server via lake setup-file's
dynlibs/plugins. This is the same pattern MD4Lean uses for its md4c FFI.

Rather than forcing the native-compile cost on every consumer, this PR gates
it behind a require option, off by default — with no option passed,
get_config? precompile is none and behavior is byte-identical to today
(ix unaffected). Consumers opt in with:

[[require]]
name = "Blake3"
git = "https://github.com/argumentcomputer/Blake3.lean"
rev = "..."
options = {precompile = "on"}

or in a lakefile.lean:

require Blake3 from git "..." @ "..."
  with NameMap.empty.insert `precompile "on"

The option is applied to all three libs (Blake3, Blake3C, Blake3Rust)
for symmetry; only libs a consumer actually builds/imports are affected.

Validated end-to-end in argument-website (with this exact get_config?
gating applied to the dependency checkout): lake setup-file on a post
importing Blake3.C lists libBlake3_Blake3C.so/libBlake3_Blake3.so for
editor workers, and a scripted LSP session evaluating #eval Blake3.C.hash …
live produces correct digests with zero missing-native errors.

Note for consumers: require options take effect at dependency
materialization, so run lake update Blake3 after adding them — a plain
rebuild is not enough. (Lake also silently ignores unknown require keys in
TOML, so a typo in options fails without a diagnostic.)

Downstream packages that run Blake3 hashing inside `#eval` at
elaboration time (e.g. Verso blog posts) need the FFI symbols loaded
into the elaborating process — in batch `lake build` and in
language-server file workers alike. Lake's mechanism for this is
`precompileModules`: the lib's shared library (which bundles the
moreLinkObjs native objects) is then built and auto-loaded for
importers, the same pattern MD4Lean uses.

Rather than forcing every consumer to pay the native-compile cost,
gate it behind a require option, off by default:

    [[require]]
    name = "Blake3"
    git = "..."
    rev = "..."
    options = {precompile = "on"}

or in a lakefile.lean:

    require Blake3 from git "..." @ "..."
      with NameMap.empty.insert `precompile "on"

With no option passed, behavior is identical to before.
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