[Toybox] Shell Compatibility Reports from Oils - ~800 tests passing

[Rob Landley]

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