Files
oh-my-pi/scripts/host-detect.ts
T
zero 82436b0e93 fix(natives): make Windows-host builds and addon loading work end to end
Runtime: the loader's AVX2 probe used [System.Runtime.Intrinsics.X86.Avx2]
via powershell.exe, which only exists on .NET Core — stock Windows PowerShell
5.1 raised TypeNotFound, so every Windows host silently loaded the baseline
addon and paid ~270ms for the spawn on the startup path. Ask the kernel via
bun:ffi (IsProcessorFeaturePresent(PF_AVX2_INSTRUCTIONS_AVAILABLE), ~0.5ms)
and fall back to pwsh-then-powershell for Node embeds. scripts/host-detect.ts
shared the same broken probe for build-time variant selection.

Build: `bun run build:native` on a win32 host died deep inside the bazel msvc
repo rules (linux/mac exec hosts only, by design). The `host` pseudo-target
now delegates to the local napi build against real VS Build Tools, and other
targets fail fast with guidance. build-bindings.ts resolves the @napi-rs/cli
JS entry from its manifest (the node_modules/.bin shim is a PE launcher Bun
cannot parse) and auto-appends VS Build Tools' bundled CMake/Ninja to PATH
via vswhere so a vcvars prompt is no longer required. Cap maudio at
opt-level=1 to dodge a rustc ICE codegenning MaybeUninit<ma_fence> for
x86_64-pc-windows-msvc under the pinned nightly (Bazel's older pin is
unaffected).

Compile: Bun.Glob.scan yields backslash paths on Windows; the legacy Pi
virtual module used them verbatim for export keys and generated identifiers,
producing invalid JavaScript in compiled-binary builds.

Tests: strip ConPTY negotiation escapes in the pty argv test; ignore the
bazel-oh-my-pi convenience symlink.
2026-08-07 16:54:02 +08:00

55 lines
1.6 KiB
TypeScript

import { dlopen, FFIType } from "bun:ffi";
import * as fs from "node:fs";
function runCommand(command: string, args: string[]): string | null {
try {
const result = Bun.spawnSync([command, ...args], { stdout: "pipe", stderr: "pipe" });
if (result.exitCode !== 0) return null;
return result.stdout.toString("utf-8").trim();
} catch {
return null;
}
}
export function detectHostAvx2Support(): boolean {
if (process.arch !== "x64") return false;
if (process.platform === "linux") {
try {
const cpuInfo = fs.readFileSync("/proc/cpuinfo", "utf8");
return /\bavx2\b/i.test(cpuInfo);
} catch {
return false;
}
}
if (process.platform === "darwin") {
const leaf7 = runCommand("sysctl", ["-n", "machdep.cpu.leaf7_features"]);
if (leaf7 && /\bAVX2\b/i.test(leaf7)) return true;
const features = runCommand("sysctl", ["-n", "machdep.cpu.features"]);
return Boolean(features && /\bAVX2\b/i.test(features));
}
if (process.platform === "win32") {
// `[System.Runtime.Intrinsics.X86.Avx2]` only exists on .NET Core, so the
// PowerShell probe reported `false` on every host whose `powershell.exe`
// is Windows PowerShell 5.1 (.NET Framework) — i.e. a stock Windows box —
// silently downgrading AVX2 machines to the baseline ISA. Ask the kernel
// instead: PF_AVX2_INSTRUCTIONS_AVAILABLE == 40.
try {
const kernel32 = dlopen("kernel32.dll", {
IsProcessorFeaturePresent: { args: [FFIType.u32], returns: FFIType.i32 },
});
try {
return kernel32.symbols.IsProcessorFeaturePresent(40) !== 0;
} finally {
kernel32.close();
}
} catch {
return false;
}
}
return false;
}