[Toybox] Shell Compatibility Reports from Oils - ~800 tests passing
Rob Landley
rob at landley.net
Tue Jul 1 10:52:08 PDT 2025
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/bootstrap
Going 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-list
To 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/build
That'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=PB5X0002US
Add 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.sh
And 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"; }
done
I 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 can
>>
>> it'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
More information about the Toybox
mailing list