On Tue, Jul 1, 2025 at 1:52 PM Rob Landley <r...@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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
