fix android support - #17
Merged
Merged
Conversation
…ds resumable Android/Termux detection (src/tauraro_install.tr): detect_os() previously had no way to distinguish real Linux from Termux (a real Linux userland on Android) -- both report `uname -s` = "Linux", so install-tauraro picked the "linux-arm64" package, which is dynamically linked against the host distro's glibc with a hardcoded dynamic-linker path that doesn't exist under Termux's own sandboxed filesystem layout (/data/data/com.termux/files/usr/...). Added is_android_termux() (checks $PREFIX for "com.termux", `uname -o`, then the filesystem path as a last resort) so Android devices now correctly resolve to the statically-linked tauraroc-android-arm64 build instead. Resumable downloads with progress caching (src/progress.tr): a sidecar state file next to the download destination records which URL its partial bytes belong to. download_with_progress() and its _single() fallback both check it before starting: a matching partial download (same URL, some bytes already on disk) resumes via curl's `-C -` instead of restarting from zero, whether the previous attempt was interrupted by a dropped connection, a stall-triggered internal retry, or the whole process being killed/Ctrl+C'd and re-run later. The state file is written BEFORE curl starts specifically so a mid-download crash still leaves enough on disk to resume from, and is cleared on success (or discarded in favor of a clean restart if the saved URL doesn't match -- e.g. retrying against the tauraro.org mirror after GitHub failed, or requesting a different version against the same destination path). This applies to every large download taupkg does, not just install-tauraro: src/installer.tr's archive-source package installs (`kind == "archive"`, used for .zip/.tgz/.tar.gz dependency URLs) now go through the same download_with_progress() instead of a bare one-shot curl call, so an interrupted `taupkg add`/`install` for an archive dependency also resumes on retry instead of re-downloading the whole archive. tmp_file's path is already stable per (project, package name), which is what makes resume across process restarts possible. Unrelated but blocking bug found and fixed while verifying the above actually compiles: src/main.tr's `from cli import ... CliArgs` was resolving against std.cli's CliArgs (added to the tauraro compiler's stdlib this month) instead of taupkg's own local src/cli.tr, since both modules share the bare name "cli" and the resolver prefers the stdlib match. This broke taupkg's build entirely against any tauraro compiler built after std.cli landed -- not something either of my changes above introduced, but something I had to fix to verify they compile at all. Renamed the local module to src/cliargs.tr (only import site was main.tr) to remove the name collision. Verified: `tauraroc --check src/main.tr` passes, and a full build runs (`taupkg version`, `taupkg help`) against a freshly-built tauraro v0.0.9 compiler.
is_android_termux() only checked Termux-specific signals ($PREFIX
containing "com.termux", the Termux filesystem path), so taupkg running
under a proot-based distro (UserLAnd, Andronix, GNURoot, ...) -- a real
Ubuntu/Debian/Alpine guest hosted on the same Android device, not Termux
itself -- would fall through to detect_os() == "linux" and pull the
dynamically-linked linux-arm64 build, which fails there for the exact
same "no matching dynamic-linker path" reason it fails under Termux.
Renamed to is_android() and layered the detection from most-general to
most-specific so it works across whichever app is hosting the shell:
1. `getprop` succeeding -- an Android system binary that doesn't exist
on any non-Android Linux system, checked first because it
generalizes across every environment rather than any one app we
happened to think of.
2. /system/build.prop existing -- part of the Android OS itself,
visible from any environment that can see /system.
3. ANDROID_ROOT / ANDROID_DATA env vars -- set by the Android runtime
for native processes.
4. Termux specifically, broadened to match any Termux package id
(com.termux, com.termux.nightly, F-Droid vs. Play Store builds,
...) via a substring check instead of one exact id, plus the
existing uname -o and filesystem-path checks as final fallbacks.
The android-arm64 release asset this resolves to is already a
statically-linked build with no host-distro dependency at all (see the
tauraro repo's build-termux-android CI job), so it was already portable
across any Android Linux environment -- only the DETECTION was narrower
than the binary it points at.
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.
No description provided.