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

[enh]

On Tue, Jul 1, 2025 at 1:52 PM Rob Landley <rob at landley.net> wrote:
>
> 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...)

c23 does not include this, and i don't think i've seen a proposal to
standardize it. +Alejandro Colomar pays more attention to wg14 though,
so he might know better...

> Sadly, standards remain a frame of reference to diverge from...
>
> Rob