feat(build): publish androidNativeArm32/Arm64 from the six downstream modules - #1239
Merged
Merged
Conversation
… modules
skainet-io-core, skainet-lang-core, skainet-compile-core, skainet-io-safetensors
and skainet-lang-ksp-annotations already target Android native. The rest of the
chain a device consumer needs does not, so SKaiNET-transformers' gemma-iree fails
to resolve at configuration time:
Could not determine the dependencies of task
':llm-runtime:gemma-iree:compileKotlinAndroidNativeArm32'.
> Could not resolve sk.ainet.core:skainet-compile-dag / -compile-opt /
-io-gguf / -backend-api.
Adds the two targets to skainet-io-gguf, skainet-lang-dag, skainet-compile-dag,
skainet-compile-opt, skainet-backend-api and skainet-backend-cpu.
None of the five hand-declared modules carries posix-typed code, so arm32's
Int-width ssize_t/size_t needs no 64-bit split source set — the reason
skainet-io-core has one does not apply. skainet-backend-api wires the new source
sets onto nativeMain by hand, matching how it declares the rest of its hierarchy.
skainet-backend-cpu opts in through the convention plugin's existing
skainet.targets property and gets a platformDefaultCpuOpsFactory actual. That
actual is a copy of the Linux one rather than a dependsOn(linuxMain): Android
native is Linux-based but bionic, not glibc, and linuxMain is free to grow code
that assumes the latter.
Supersedes most of #990, whose io-core half develop has since landed
independently and whose io-gguf half conflicts with the RandomAccessSourceFactory
consolidation. Its exportMain split is no longer needed either: that existed to
keep export tooling off arm32 because it needs compile-dag, which now has the
target.
Verified: compileKotlinAndroidNativeArm32 and Arm64 green for all six; jvmTest
and repo-wide apiCheck unchanged; and via composite build, transformers'
:llm-runtime:gemma-iree:compileKotlinAndroidNativeArm32 — the task that fails on
SKaiNET-transformers#315 — now succeeds.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YKeDSK4JF295y53Uvez954
3 tasks
|
📖 Documentation Preview The documentation has been built successfully for this PR. Generated Files:
Artifacts:
This comment will be updated automatically when the PR is updated. |
… too
The first pass added the targets to the six modules a device consumer needs, but
only ever compiled their MAIN source sets locally. CI's assemble also configures
the test compilations, and those pull in modules the target set did not reach:
Could not determine the dependencies of task
':skainet-backend-cpu:compileTestKotlinAndroidNativeArm32'.
> Could not resolve project ':skainet-lang:skainet-lang-models'.
A target set has to close over test dependencies, not just main ones. Adding
androidNative to skainet-lang-models pulls in skainet-compile-json (its own
commonTest needs it), and compile-json's tests need lang-models straight back, so
the two of them close the cycle: main deps of both were already covered.
compile-json also needed a writeExportToFile actual. Its native actuals are all
the same NotImplementedError stub duplicated per target; this one covers both
androidNative targets in a single androidNativeMain file, which the default
hierarchy template groups for us.
Verified with the task CI actually failed on this time: assemble is green, as are
compileTestKotlinAndroidNativeArm32 across the affected modules, apiCheck, and
their jvm suites.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YKeDSK4JF295y53Uvez954
|
📖 Documentation Preview The documentation has been built successfully for this PR. Generated Files:
Artifacts:
This comment will be updated automatically when the PR is updated. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
skainet-io-core,skainet-lang-core,skainet-compile-core,skainet-io-safetensorsandskainet-lang-ksp-annotationsalready target Android native. The rest of the chain a device consumer needs does not — so SKaiNET-transformers'gemma-ireefails at configuration time, which is what turns SKaiNET-transformers#315 CI red:What
Adds
androidNativeArm32+androidNativeArm64to the six remaining modules:skainet-io-gguf,skainet-lang-dag,skainet-compile-dag,skainet-compile-opt,skainet-backend-api,skainet-backend-cpu.Two notes on how, since the 32-bit target has a reputation:
skainet-io-coreneeds one because arm32's posixssize_t/size_tareIntwhere every other native target hasLong, and mixing widths fails the shared native metadata compile. None of these five hand-declared modules has posix-typed code at all, so that reason doesn't reach them.skainet-backend-apiwires the new source sets ontonativeMainby hand, matching how it declares the rest of its hierarchy.skainet-backend-cpuopts in through the convention plugin's existingskainet.targetsproperty — the mechanism was already there, unused — and gets aplatformDefaultCpuOpsFactoryactual. That actual is a copy of the Linux one rather than adependsOn(linuxMain): Android native is Linux-based but it is bionic, not glibc, andlinuxMainis free to grow code that assumes the latter. Six duplicated lines beat inheriting that silently.Relationship to #990
This supersedes most of #990, which is 269 commits behind and conflicting:
skainet-io-corehalf develop has since landed independently — the target, thenative64Mainsplit and thePosix32Preadactual are all on develop already.skainet-io-ggufhalf conflicts with a refactor:RandomAccessSourceFactory's six platform actuals were consolidated into onecommonMainfile, so thenative.kt → native64.ktrename it wants no longer has a file to rename.exportMainsplit is no longer necessary. That existed to keepGgufExportFacade/GGUFWriteroff arm32 because they needcompile-dag— which this PR gives the target, so the split solves nothing.What remained of #990 was the downstream target list, which is this PR. Suggest closing #990 in favour of it.
Verification
compileKotlinAndroidNativeArm32— all six modulescompileKotlinAndroidNativeArm64— all six modulesjvmTest— backend-api, backend-cpu, io-ggufapiCheck:llm-runtime:gemma-iree:compileKotlinAndroidNativeArm32via composite build🤖 Generated with Claude Code
https://claude.ai/code/session_01YKeDSK4JF295y53Uvez954