Runtime should ship with the compiler/CLI, not live in a project's ludic_modules #75

New issue

Closed

opened 2026-09-02 04:52:38 +02:00 by orkun · 1 comment

orkun commented

2026-09-02 04:52:38 +02:00

Owner

A game project currently must expose the engine runtime (runtime/native/*) under its module root, because the compiler resolves the auto-spliced runtime/native/core.ludic through the $LUDIC_MODULES fallback (default ludic_modules/). That forces every project to symlink or copy the native + web build runtime into ludic_modules.

The runtime is part of the toolchain, not the project. The compiler/CLI should locate and splice its own runtime from its install (e.g. LUDIC_HOME/runtime or embedded), independent of the project's package module root. ludic_modules/ should hold only third-party packages.

Found while setting up an external game repo that consumes the ludic.* controller packages.

A game project currently must expose the engine runtime (runtime/native/*) under its module root, because the compiler resolves the auto-spliced `runtime/native/core.ludic` through the `$LUDIC_MODULES` fallback (default `ludic_modules/`). That forces every project to symlink or copy the native + web build runtime into `ludic_modules`. The runtime is part of the toolchain, not the project. The compiler/CLI should locate and splice its own runtime from its install (e.g. `LUDIC_HOME/runtime` or embedded), independent of the project's package module root. `ludic_modules/` should hold only third-party packages. Found while setting up an external game repo that consumes the ludic.* controller packages.

orkun referenced this issue from a commit

2026-09-02 06:49:12 +02:00

feat(compiler): #75 resolve the auto-spliced engine runtime from LUDIC_HOME

orkun commented

2026-09-02 06:49:24 +02:00

Author

Owner

Shipped in ab4546e (full suite 113/0, goldens byte-identical, C-free bootstrap fixpoint intact).

The compiler auto-splices runtime/native/* for any ECS game, but it resolved that import relative to the build CWD and then fell back to the package module root ($LUDIC_MODULES, default ludic_modules/) — which is exactly why an external game had to copy or symlink the engine runtime into ludic_modules/.

Fix: do_import now treats a runtime/... path specially — when it isn't found relative to the build, it's resolved from the install root $LUDIC_HOME (default: the compiler binary's directory, the same place main.ludic already finds cocoa.ll / audio.ll / http.ll), before the package module root. So the runtime comes from the toolchain install, and ludic_modules/ holds only third-party packages.

Backward-compatible: in-repo builds still resolve the runtime locally (CWD = repo root), so the $LUDIC_HOME fallback never fires there and the emitted IR / fixpoint are untouched. Verified with a hermetic test that builds an ECS game from an external CWD that deliberately has no runtime/ and no ludic_modules/ under it — it compiles and runs, resolving the engine runtime purely from LUDIC_HOME. Documented in docs/PACKAGES.md.

Shipped in ab4546e (full suite 113/0, goldens byte-identical, C-free bootstrap fixpoint intact). The compiler auto-splices `runtime/native/*` for any ECS game, but it resolved that import relative to the build CWD and then fell back to the **package module root** (`$LUDIC_MODULES`, default `ludic_modules/`) — which is exactly why an external game had to copy or symlink the engine runtime into `ludic_modules/`. Fix: `do_import` now treats a `runtime/...` path specially — when it isn't found relative to the build, it's resolved from the install root **`$LUDIC_HOME`** (default: the compiler binary's directory, the same place `main.ludic` already finds `cocoa.ll` / `audio.ll` / `http.ll`), **before** the package module root. So the runtime comes from the toolchain install, and `ludic_modules/` holds only third-party packages. Backward-compatible: in-repo builds still resolve the runtime locally (CWD = repo root), so the `$LUDIC_HOME` fallback never fires there and the emitted IR / fixpoint are untouched. Verified with a hermetic test that builds an ECS game from an external CWD that deliberately has **no** `runtime/` and **no** `ludic_modules/` under it — it compiles and runs, resolving the engine runtime purely from `LUDIC_HOME`. Documented in docs/PACKAGES.md.

orkun closed this issue

2026-09-02 06:49:24 +02:00