Orkuncakilkaya
ab4546e365
The compiler auto-splices runtime/native/* for any ECS game, but resolved it relative to the build CWD, then fell back to the package module root ($LUDIC_MODULES) — forcing every external project to copy/symlink the engine runtime into ludic_modules/. The runtime is part of the toolchain, not the project: do_import now resolves a runtime/... import that isn't found locally from $LUDIC_HOME (default: the compiler binary's dir — where cocoa.ll/audio.ll already come from), before the module root. So ludic_modules/ holds only third-party packages. In-repo builds are byte-identical (the runtime resolves locally there, so the $LUDIC_HOME fallback never fires; fixpoint holds). Verified by a hermetic test that builds an ECS game from an external CWD with no runtime/ or ludic_modules/ under it, resolving the runtime from LUDIC_HOME. Full suite 113/0. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
805 B
bump: minor
type: feat
The engine runtime ships with the toolchain, not the project (#75). The compiler auto-splices runtime/native/* for any ECS game; a runtime/... import that is not found relative to the build is now resolved from the install root $LUDIC_HOME (default: the compiler binary's directory — where the platform .ll files already come from) before the package module root. So an external game that consumes the ludic.* packages no longer has to copy or symlink the engine runtime into its ludic_modules/; that directory holds only third-party packages, and the runtime is part of the toolchain install. In-repo builds are byte-identical (the runtime still resolves locally there, so the $LUDIC_HOME fallback never fires and the C-free bootstrap fixpoint is untouched).