On 7/1/25 11:16, enh wrote:
I don't know much about Android -- is this at all realistic for FIVE packages -- if you add mksh, which I believe is the Android system shell ?Eh, define realistic. AOSP is built around git (kind of conceptually), and their build infrastructure uses python 3. So you'd build a system to build a system.AOSP includes its own clang, its own soong/ninja/make, its own bison/flex, its own python... bash is one of the few exceptions that come from the host: https://android.googlesource.com/platform/build/soong/+/master/ui/build/paths/config.go#86
"Building a system to build a system" would initially be creating a chroot within which AOSP ran with all its prebuilts (so providing the required external dependencies in a way that could theoretically be added to AOSP base), but would _then_ involved hermetically rebuilding the prebuilts.
Although honestly, half what I did with LFS was untangle what it was doing so I could make a less complex but equivalently functional system. Even the automated builder was generic build infrastructure:
https://github.com/landley/control-images/tree/master/common/bootstrapGoing over a package list in order (with comments that let grep -v filters drop out package categories):
https://github.com/landley/control-images/blob/master/images/lfs-bootstrap/mnt/package-listTo call individual build scripts, many of which were symlinked together to a generic build script that could handle a "normal" package:
https://github.com/landley/control-images/tree/master/images/lfs-bootstrap/mnt/buildThat's not exactly how AOSP upstream does it, but was provably equivalent. :)
AOSP is a large edifice with its own significant domain expertise. Which Elliott has (and I do not), but he manages a large team and last I checked didn't have a lot of spare bandwidth for cleaning up stuff that already works.
Can Android even be built on Android at all, with any number of packages? e.g. if you download all the dev tools onto an Android device ... I imagine it is a ton of tools, and not very fun.That's an Elliott question,could you? yes. would you want to? not if you value your time.
It's feasible. You can buy a new Android phone for $200 with 4 gigs ram (plus 8 gigs swap) with 2.4 ghz 8xSMP processor and can use a 1 TB sdcard.
https://www.motorola.com/us/en/p/phones/moto-g/moto-g-2025/pmipmhh39mq?pn=PB5X0002USAdd a USB hub, keyboard, mouse, and video adapter to hook it up to a TV (I _used_ to say chromecast but Google discontinued those last year, I assume there's some sort of replacement or maybe https://en.wikipedia.org/wiki/USB_video_device_class finally means something) and you can theoretically use a phone as a workstation.
Current AOSP is resource intensive enough that the last time I built it on my laptop it ran overnight and into the next day, but that's a separate issue. The above phone (not even one the cheap chinese ones) is faster than my laptop and I do real work on it. (Although I did upgrade my laptop's ram to 16tb, because I could.)
(and note that prebuilt-wise, we currently support darwin/arm64 but not linux/arm64. only linux/x86-64.)
Back under aboriginal I tried to cross compile everything from everything once (build a powerpc->mips cross compiler and run it under qemu to create a mips chroot) but combinatorial stuff gets uncomfortable fast.
But "build and run on the host without having to be told what the host is" was generally quite doable. That's why I put it through such a small bottleneck though: those base 7 packages building on Linux distros I'd never heard of was always 50 times as much trouble "something uniquely broke on S390".
I remember when Wolfgang Denk (the u-boot guy) tried Aboriginal and it broke spectacularly because he had a whole bunch of weird environment variables set, so I created an environment variable sanitizer with a big whitelist:
https://github.com/landley/aboriginal/blob/master/sources/variables.shAnd then for mkroot I just used "exec env -i $0 $@" passing through $HOME and $PATH (and 4 API variables I was used to providing as prefixes), and then had one line in a for loop grab the NAME=VALUE arguments and export set them as environment variables, and keep the rest of the arguments as additional packages to build out of mkroot/packages. Currently mkroot/mkroot.sh starts with:
# Clear environment variables by restarting script w/bare minimum passed through
[ -z "$NOCLEAR" ] && exec env -i NOCLEAR=1 HOME="$HOME" PATH="$PATH" \
LINUX="$LINUX" CROSS="$CROSS" CROSS_COMPILE="$CROSS_COMPILE" "$0" "$@"
# assign command line NAME=VALUE args to env vars, the rest are packages
for i in "$@"; do
[ "${i/=/}" != "$i" ] && export "$i" || { [ "$i" != -- ] && PKG="$PKG
$i"; }
doneI spent many years figuring out what I could throw away. That quote from the guy who wrote "The Little Prince" was my email sig for a while:
https://www.goodreads.com/quotes/19905-perfection-is-achieved-not-when-there-is-nothing-more-to
Still on the TODO list for the new stuff. Back in the day I could get about -j3 usefully going before the emulator became the bottleneck. Well using SMP for the actual compile part, the configure stage was 100% the bottleneck in all the gnu package builds. Still is. More totally unnecessary gnu/stupid: the compiler sets a zillion builtin macros you can see with: $ :|cc -dM -E - And between that, c11's __has_include(), and features.h you canit's been implemented by clang/gcc for a long time, but if you're going to be a standards lawyer about it, __has_include() is c++17 and c23.
Sigh. Did one of the standards finally include gcc's empty ? : middle argument? (Which I use all the time...)
Sadly, standards remain a frame of reference to diverge from... Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
