Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Ground truth: add Kotlin/Native target(s) to skainet-test-groundtruth (jvm/android only today)

Open
  • Is something wrong?
#1,301 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
kotlin
Domain
testing

Research direction

Start with skainet-test/skainet-test-groundtruth/build.gradle.kts and inspect its kotlin { } targets and the commonMain dependencies, especially whether skainet-io-gguf supports Kotlin/Native. Check whether fixture generation needs changes or only Kotlin consumption. Done when a Kotlin/Native-only module can depend on the ground-truth validator and its fixtures; macosArm64() is the suggested first target.

Written by the indexing model from the issue text.

Description

enhancement platform skill:native sub-issue

Problem

skainet-test-groundtruth's kotlin { } block only declares android() and jvm() targets (skainet-test/skainet-test-groundtruth/build.gradle.kts). There's no macosArm64() / iosArm64() / linuxX64() / any Kotlin/Native target at all.

That makes GroundTruthValidator(ops, factory) unusable from any Kotlin/Native-only consumer — for example an out-of-tree GPU backend that only publishes K/N targets (macOS/iOS) and has no JVM target to fall back to. Right now the only way to get any ground-truth coverage for a backend like that is to hand-roll independent fixtures outside the module entirely, which duplicates exactly the hand-written-mapping problem #985/#986/#988 are already trying to avoid on the JVM/Python side.

Ask

Add at least one Kotlin/Native target (macosArm64 would cover the common Apple-Silicon dev case) to skainet-test-groundtruth, so GroundTruthValidator and its fixtures can be consumed by K/N-only modules the same way the skainet-backend-cpu src/goldenTest pattern already works on the JVM side.

Things worth checking first:

  • Does GGUF fixture loading (skainet-io-gguf) already build for K/N targets?
  • Does anything in commonMain currently reach for a jvm()-only API?
  • Does the Docker/PyTorch fixture-generation step need to change, or only the Kotlin consumption side?

Context

Ran into this concretely while trying to wire ground-truth validation into an out-of-tree, Kotlin/Native-only MLX/Metal backend module — ended up redefining that task around a small hand-written independent NumPy fixture instead, since the module couldn't be depended on at all from a K/N-only target set.

Related: #984, #985, #988.

Dominant language
Kotlin
Stars
52
Forks
15
Avg merge
1d 8h
Merged PRs (30d)
37

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SKaiNET-developers/SKaiNET

All issues in SKaiNET-developers/SKaiNET

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.