an alternative to TOYBOX_ON_ANDROID would be to just "default n" those toys, and rely on the fact that Android has its own hand-maintained .config file(s) anyway...
(but probably not worth doing that without having a way to drop TOYBOX_FORK too.) On Fri, Dec 5, 2025 at 4:40 PM Rob Landley <[email protected]> wrote: > > I wrote this on the 25th and then left my laptop suspended+unplugged too > long so the battery died and I lost all my open windows. I ignored it > over the holidays (deal with it on monday), then sunday night I dropped > my phone and smashed the screen (the replacement part presumably arrived > today). > > Anyway, here's what I fished out of the drafts folder... > > On 11/20/25 12:29, enh wrote: > >> But yeah, native builds under emulation with distcc calling out to the > >> cross compiler on the host would always boil down to each package going > >> "autoconf runs for 5 minutes, then the actual compile takes 12 seconds" > > > > to be fair, i'm pretty sure that's the default autoconf experience... > > it's always a joy to see 127 of my 128 cores idle through the endless > > "configure" part and then the "make" part being so fast i can barely > > measure it. > > Between __has_include(), the output of ":|cc -E -dM -", and posix-2008, > 99.5% of what autoconf does has been useless for at least 15 years. (If > you include LP64 or even just trust sizeof(long) to be a compile time > constant with dead code elimination, you're close to 100%.) > > (Note: toybox's 7 year time horizon was about interfacing with SOFTWARE. > For _hardware_ I only switched the prebuilt toolchains from i686 to > x86-64 static binaries in 2023, commit 3690494282cf.) > > > (especially because the configure part is the part that's most likely > > to fail and need you to retry [for stuff you don't actively work on > > yourself], so you get to see it over and over. and while cmake's > > equivalent system's caching helps with that, caching brings the usual > > set of cache invalidation problems.) > > Terrifyingly, autoconf also has cacheing. (Nobody ever uses it, it's > broken half the time and doesn't save nearly as much time as it should, > but the plumbing's been there forever.) > > But seriously, autoconf does NOT NEED TO EXIST anymore. If ld's > --as-needed didn't gratuitously error on libraries that aren't there (I > just TOLD it that it's ok NOT to use this library, why are you flipping > out if this system hasn't got it?) then toybox's scripts/genconfig.sh > would have exactly two probes left: > > 1) TOYBOX_ON_ANDROID is really a sequencing issue (menuconfig wants to > #ifdef __ANDROID__, maybe building the new kconfig binary can assert a > symbol for that? > > 2) TOYBOX_FORK is because nobody's ever agreed on an #ifdef for nommu > (so we check that fork() is _not_ present in libc). It would be > __FDPIC__ except nommu never did a consistent fdpic conversion (binflt > was an a.out variant that's long dead except the hardware still > deploying 2.6 kernels on devices love it. The coldfire maintainer just > uses static pie rather than try to interface with the gcc loons to get > fdpic support into the toolchain, I've blogged about that. I spent years > trying to get people like Jeff to engage with the open source software > community instead of getting what they want working once and then > calling it good and never upgrading again. Alas recently the community's > changed to give much more weight to their position, and I haven't > decided what to do about that. Moving from GPL 2 to 0BSD when GPL 3 > happened was a bit of an adjustement for me. Moving off of Linux isn't a > smaller lift...) > > Anyway, both those are kconfig symbols that probably should be recording > #ifdefs used to build the kconfig binary. I need an "ifdef __FDPIC__ > TOYBOX_NOFORK" syntax or some such in Config.in. (I need to write a > menuconfig, which is like a weekend, but I just haven't had the enthusiasm.) > > Rob > > P.S. Hmmm... the problem with adding ifdef __ANDROID__ TOYBOX_ON_ANDROID > to the config syntax is A) you have to resolve the first symbol at > compile time, not runtime, B) if you _did_ it would be $HOSTCC not the > target compiler. > > I mean I guess I could have scripts/make.sh go: > > :|cc -E -dM - | sed 's/#define \([^ ]*\) .*/\1/' > generated/ifdefs > > And then have kconfig read that at runtime? Hmmm. Question of which is > less ugly. (I really want to have a scripts/config.sh to avoid the gmake > dependency for config, that's always been one of the warts I want the > kconfig rewrite to remove. Generating the target #ifdef list should > really be at kconfig runtime not at build time, but I don't really want > kconfig to call out to the compiler...) > _______________________________________________ > Toybox mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
