Comment by acuozzo
20 hours ago
Technical? No. Social? Yes.
Fixing it would require an unprecedented level of cooperation across multiple industries.
20 hours ago
Technical? No. Social? Yes.
Fixing it would require an unprecedented level of cooperation across multiple industries.
I’d argue there isn’t a social justification for the shit show, but rather just social reasons
The justification emerges when you start thinking about how to build a true "package management" system for C libraries which embraces the fact that a world exists beyond GNU/Linux on x86_64.
At some point you realize that not even the (in)famous "host triple" has sufficient coverage for the fractal complexity of the real world.
C and its toolchain are where so many of these tedious little differences are managed. Making tools which account only for the 80% most common use-case defeats the purpose.
How would one encode e.g. "this library targets only the XYZ CPU in Q mode for firmware v5-v9 and it compiles only with GCC v2.95"?
The tools in use need to be flexible enough to handle cases like this with grace or you just end up reinventing GNU Autotools and/or managing your build with a hairy shell script of your own making.
The GNU Autotools system organically grew from dealing with the rapidly-changing hardware and software landscape of the 1980s-1990s. DIY shell scripts were organized, macros were written, and a system was born.
If embedded folk have to start writing their own scripts to handle the inevitable edge cases which WILL come up, then what is a new build tool really accomplishing-- Autotools, but in Python?
That is not a _justification_ - merely an _explanation_ of how we got here. I fully agree that a historical understanding of how we got to where we are is essential for understanding why we have what we have. However, it's critical to not conflate the history and evolution as a justification for why the current system sucks so much! I agree there is a massive amount of complexity and branching to consider, but autotools and the whole C ecosystem does a terrible job of tackling that complexity, and introduces a huge amount of accidental complexity into the solution space.
The co-evolution of hardware, software, and all other moving targets has landed us in a fairly abysmal local maxima. More recently developed toolchains (e.g. zig, rust, etc.) show us that there are much better ways to tackle these problems. Of course they introduce other ones, but we can do so much better.