You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SKaiNET's KMP modules publish linuxX64, linuxArm64, macosArm64, iOS and androidNative targets — but no mingwX64 (and no macosX64). A Kotlin/Native application targeting Windows cannot resolve skainet-lang-core, skainet-backend-cpu, or any skainet-io-* artifact, so a Windows-native binary using SKaiNET is impossible today; the only Windows story is the JVM.
Root cause / scope
Target lists are declared per-module in each build.gradle.kts (#902 — default hierarchy template — and #804 — a multiplatform convention plugin — would centralize this). The pure-Kotlin modules (lang-*, backend-cpu, compile-*, io-*, data-*) show no POSIX-specific code in their target matrix; expected work:
add mingwX64() to the shared target list,
provide expect/actual fills where linux/macos actuals exist (e.g. PlatformCpuOpsFactory.*, file access in io modules — kotlinx-io supports mingwX64),
a Windows CI lane (cross-compilation from Linux hosts works for mingwX64; tests need a Windows runner or Wine).
Proposal
Add mingwX64 to the convention target list for skainet-lang-*, skainet-backend-api, skainet-backend-cpu, skainet-io-core/-gguf/-safetensors, skainet-data-api/-simple, and skainet-bom.
CI: compile-only gate on Linux cross-compile + a nightly Windows test lane.
macosX64 is deliberately out of scope (Apple-Silicon-only decision downstream); it would ride the same convention change if ever wanted.
Why now
whisper-cli (Whisper + Moonshine ASR CLI on eager CPU; the downstream consumer behind #910) ships native executables for linuxX64/linuxArm64 with byte-identical-to-JVM transcripts, and needs Windows as a first-class native target — a concrete, testable consumer for the new artifacts.
Acceptance
sk.ainet.core:skainet-lang-core, :skainet-backend-cpu, :skainet-io-gguf resolve for mingwX64 from Maven Central (or snapshots).
A hello-tensor K/N mingwX64 executable (create tensor, matmul, read back) links and runs on Windows x64.
Downstream: whisper-cli links its mingwX64 CLI binary and produces a correct golden transcript on Windows.
Problem
SKaiNET's KMP modules publish
linuxX64,linuxArm64,macosArm64, iOS and androidNative targets — but nomingwX64(and nomacosX64). A Kotlin/Native application targeting Windows cannot resolveskainet-lang-core,skainet-backend-cpu, or anyskainet-io-*artifact, so a Windows-native binary using SKaiNET is impossible today; the only Windows story is the JVM.Root cause / scope
Target lists are declared per-module in each
build.gradle.kts(#902 — default hierarchy template — and #804 — a multiplatform convention plugin — would centralize this). The pure-Kotlin modules (lang-*,backend-cpu,compile-*,io-*,data-*) show no POSIX-specific code in their target matrix; expected work:mingwX64()to the shared target list,expect/actualfills where linux/macos actuals exist (e.g.PlatformCpuOpsFactory.*, file access iniomodules — kotlinx-io supports mingwX64),Proposal
mingwX64to the convention target list forskainet-lang-*,skainet-backend-api,skainet-backend-cpu,skainet-io-core/-gguf/-safetensors,skainet-data-api/-simple, andskainet-bom.macosX64is deliberately out of scope (Apple-Silicon-only decision downstream); it would ride the same convention change if ever wanted.Why now
whisper-cli (Whisper + Moonshine ASR CLI on eager CPU; the downstream consumer behind #910) ships native executables for linuxX64/linuxArm64 with byte-identical-to-JVM transcripts, and needs Windows as a first-class native target — a concrete, testable consumer for the new artifacts.
Acceptance
sk.ainet.core:skainet-lang-core,:skainet-backend-cpu,:skainet-io-ggufresolve formingwX64from Maven Central (or snapshots).mingwX64executable (create tensor, matmul, read back) links and runs on Windows x64.mingwX64CLI binary and produces a correct golden transcript on Windows.