The manifest pinned `[build] runtime = "../../../runtime/wovm"`, a repo-only relative path that overrides woc's runtime resolution — so `woc <copied-dir>` failed off-repo (e.g. an installed toolchain on a test server) with "runtime binary not found". - Drop the [build] section: the project no longer hardcodes a machine path, so an installed `woc` self-locates `wovm` beside its own binary. - The module justfile's `build` recipe now sets WO_RUNTIME=<repo>/runtime/wovm so the in-repo build still uses the freshly built VM. - Acceptance is unaffected (it compiles via `woc --emit` + an explicit $WOVM, never the manifest [build] key). Verified: just log-watcher::build OK; just log-watcher 7/0; and building a copied tree with the installed-layout woc from an unrelated cwd self-locates the sibling wovm and produces a runnable binary. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
16 lines
763 B
TOML
16 lines
763 B
TOML
name = "log-watcher"
|
|
version = "0.1.0"
|
|
description = "The Haxe log-watcher ported file-for-file: the systems-track sample workload (program mode + fs/proc/net/time/json)"
|
|
|
|
# A free `fn main` makes this a PROGRAM (systems-track spec Part 2): one
|
|
# shard, blocking builtins legal, exit code = main's return value. No [app]
|
|
# listen — the mcp subcommand takes its port from config.json, like the
|
|
# original.
|
|
|
|
[runtime]
|
|
wo = ">= 0.1"
|
|
|
|
# `woc <dir>` builds target/log-watcher from this manifest. No runtime path is
|
|
# pinned here so the project is portable: an installed `woc` finds `wovm` beside
|
|
# its own binary. For an in-repo build, point woc at the freshly built VM with
|
|
# WO_RUNTIME=<repo>/runtime/wovm — the module justfile's `build` recipe does.
|