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?
I like C/C++ a lot, A LOT, and I agree with your comment.
Man, if this got fixed it would be one of the best languages to develop for.
My wishlist:
* Quick compilation times (obv.) or some sort of tool that makes it feel like an interpreted language, at least when you're developing, then do the usual compile step to get an optimized binary.
* A F...... CLEAR AND CONSISTENT WAY TO TELL THE TOOLCHAIN THIS LIBRARY IS HERE AND THIS ONE IS OVER THERE (sorry but, come on ...).
* A single command line argument to output a static binary.
* Anything that gets us closer to the "build-once run-anywhere" philosophy of "Cosmopolitan Libc". Even if an intermediate execution layer is needed. One could say, "oh, but this is C, not Java", but it is already de facto a broken Java, because you still need an execution layer, call it stdlib, GLIB, whatever, if those shared libraries are not on your system with their exact version matching, your program breaks ... Just stop pretending and ship the "C virtual machine", lmao.
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?
1 reply →
I like C/C++ a lot, A LOT, and I agree with your comment.
Man, if this got fixed it would be one of the best languages to develop for.
My wishlist:
* Quick compilation times (obv.) or some sort of tool that makes it feel like an interpreted language, at least when you're developing, then do the usual compile step to get an optimized binary.
* A F...... CLEAR AND CONSISTENT WAY TO TELL THE TOOLCHAIN THIS LIBRARY IS HERE AND THIS ONE IS OVER THERE (sorry but, come on ...).
* A single command line argument to output a static binary.
* Anything that gets us closer to the "build-once run-anywhere" philosophy of "Cosmopolitan Libc". Even if an intermediate execution layer is needed. One could say, "oh, but this is C, not Java", but it is already de facto a broken Java, because you still need an execution layer, call it stdlib, GLIB, whatever, if those shared libraries are not on your system with their exact version matching, your program breaks ... Just stop pretending and ship the "C virtual machine", lmao.