nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/.claude/memory/schos-cross-platform-build.md
Nexoniarz 3182da3965 Carry project memory in the repo, with tools/memory-sync.sh 
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
2026-08-09 14:27:22 +02:00

3.1 KiB
Raw Blame History

name description metadata
schos-cross-platform-build The build and tools support Windows, Linux, macOS and BSD; clang everywhere, and the four host assumptions that used to break
node_type type originSessionId modified
memory project 9d8a2aef-bcf0-47a0-96c6-f706efab4a95 2026-08-09T12:26:54.787Z

Nexoniarz develops from both Windows and Linux and switches between them, so nothing in the build may assume a host. As of 2026-08-09 all four are supported: Windows (Git Bash/MSYS), Linux, macOS, and the BSDs. See schunix-build-environment for why WSL is not an option on the Windows box.

One toolchain, not two. clang is a cross-compiler by construction, so a single LLVM install produces every target the tree needs — bare-metal ELF, the 16/32-bit code below 1 MB, and Linux/musl userland — from any host. The Makefile picks clang+lld whenever both are on PATH; USE_GNU=1 forces the GNU fallback. The old GNU branch had rotted: it passed --no-warn-rwx-segments, which is a hard error on lld, and lld is the default linker on FreeBSD and macOS. It also wanted a brewed x86_64-elf-gcc before a Mac could build at all.

Host tools use the host's own cc. Only mingw needs naming explicitly, and only because clang defaults to an MSVC target there while tools/mkfs.c needs <unistd.h> and <dirent.h>.

The four things that were actually host-specific, all fixed — worth recognising the pattern before adding a fifth:

  1. <sys/sysmacros.h> is glibc/musl only. macOS and the BSDs have no such header and take major()/minor() from <sys/types.h>. Guarded on __linux__ now.
  2. sha256sum -c - exists on Linux and Git Bash only. macOS has shasum -a 256, FreeBSD/NetBSD sha256, OpenBSD cksum -a sha256. tools/sha256check.sh tries all five and compares digests itself rather than trusting a -c flag, whose input format also differs.
  3. nproc is coreutils — absent on macOS and BSD, where it is sysctl -n hw.ncpu.
  4. Join-Path $root 'build\x' produces a filename containing a backslash on a Unix host. PowerShell 7 runs on Linux/macOS/BSD, so the .ps1 tools are usable there, but only with forward slashes throughout and QEMU found on PATH instead of a hardcoded scoop location.

Do not blanket-replace backslashes in the .ps1 tools. bootcheck.ps1 sends printf 'caf\303\251' to the guest to test UTF-8; rewriting those octal escapes changes what the test asserts without failing it. The sweep is restricted to known directory prefixes for exactly this reason.

Ports do not build on Windows — make ports skips with a message and the tree relies on sysroot/ being pre-staged. Building musl/toybox/mksh from source needs a Linux host. That is a real reason to keep the Linux path working, not a theoretical one.

Unverified, and say so when it matters: the Linux, macOS and BSD paths are written from documented behaviour and have never been executed — this machine has no WSL and no second host. Windows is the only host where the build and tools/bootcheck.ps1 have actually been run green.