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
