FWIW the sandbox-disabling bit in xz was in CMake logic, not autoconf. (Or at least the obvious one is in the CMake part; maybe the autoconf is separately backdoored.)
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...
Autoconf makes me think we stopped evolving too soon
11–20 of 169 posts
Re: Autoconf makes me think we stopped evolving too soon
#12You can pre-answer most autoconf sections using /etc/config.site, and a system distributor can create an /usr/share/config.site[1]. It's just really hard to get right, nobody uses it effectively. Autoconf also has a config.cache[2], which it uses to store answers to reuse across multiple of the same checks and reruns of the configure script. [1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/h... [2]: ht…
> It's just really hard to get right, nobody uses it effectively
Autoconf in a nutshell
Re: Autoconf makes me think we stopped evolving too soon
#13You can pre-answer most autoconf sections using /etc/config.site, and a system distributor can create an /usr/share/config.site[1]. It's just really hard to get right, nobody uses it effectively. Autoconf also has a config.cache[2], which it uses to store answers to reuse across multiple of the same checks and reruns of the configure script. [1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/h... [2]: ht…
I use autotools for my C++ projects and I hate it (in my weak defense, I hate cmake more). config.cache helps (and ccache helps a lot, too; most of my ccache hits are on stupid autoconf test programs; ya gotta use ccache if you use autoconf), but rerunning configure is still s l o w. Worse, automake and autoconf have a cyclic dependency, so if you're a developer (as opposed to a user building from source on a system)…
I'm be written lots of C code that runs on lots of architectures & platforms: PDPs, x86, ARM; Windows, BSD, Linux, VMS. My projects have spanned them gamut from tiny to gargantuan (millions of lines of code). I've never needed autoconf... what's it even for!?
Re: Autoconf makes me think we stopped evolving too soon
#14A huge part of the problem is relying on the system. Project repos should include their dependencies. The Linux model of global shared libraries is, imho, bad and wrong.
Building a project shouldn’t be complicated. There should be extremely minimal branching and if checks.
My blog post where I argue this in more detail: https://www.forrestthewoods.com/blog/dependencies-belong-in-...
Re: Autoconf makes me think we stopped evolving too soon
#15A better solution is just to write a plain ass shell script that tests if various C snippets compile. https://github.com/oilshell/oil/blob/master/configure https://github.com/oilshell/oil/blob/master/build/detect-pwe... Not an unholy mix of m4, shell, and C, all in the same file. --- These are the same style as a the configure scripts that Fabrice Bellard wrote for tcc and QEMU. They are plain ass shell scripts, beca…
> A better solution is just to write a plain ass shell script that tests if various C snippets compile.
Then standardize those scripts and share them so others can benefit from code reuse.
Then build a configuration tool to make it easy for everyone to define collections of tests applicable to their software.
Then create a meta-level scripting system so all of the above can be integrated into the software build process.
Then complain about how confusing and complicated the whole thing has become and start over from the beginning again.
Re: Autoconf makes me think we stopped evolving too soon
#16Earlier quoted context omitted.
I use autotools for my C++ projects and I hate it (in my weak defense, I hate cmake more). config.cache helps (and ccache helps a lot, too; most of my ccache hits are on stupid autoconf test programs; ya gotta use ccache if you use autoconf), but rerunning configure is still s l o w. Worse, automake and autoconf have a cyclic dependency, so if you're a developer (as opposed to a user building from source on a system)…
I'm be written lots of C code that runs on lots of architectures & platforms: PDPs, x86, ARM; Windows, BSD, Linux, VMS. My projects have spanned them gamut from tiny to gargantuan (millions of lines of code). I've never needed autoconf... what's it even for !?
Well, as archaic as it is, and as awful as its execution model is, autoconf is at least somewhat useful:
* determining availability of different syscalls (yay, printf)
* determining compiler
* verifying dependencies are installed and available (e.g., openssl)
This last one is made much easier with pkg-config and the pkg-config macros in autoconf. There's an argument to be made that pkg-config is bad because it will fail the build if you're just missing the wrong .pc file somewhere, even if your system satisfies the needs of the program - true enough. But pkg-config _does_ make checking for dependencies in autoconf much easier, and it does something essential for correctness, which is gathering up the necessary compilation and linker flags of your dependencies to pass along to the compiler so that you can use them correctly and match ABIs.
A good configure script will guide you through getting dependencies installed, which is much nicer for users than confronting them with compilation/linker errors.
Re: Autoconf makes me think we stopped evolving too soon
#17A better solution is just to write a plain ass shell script that tests if various C snippets compile. https://github.com/oilshell/oil/blob/master/configure https://github.com/oilshell/oil/blob/master/build/detect-pwe... Not an unholy mix of m4, shell, and C, all in the same file. --- These are the same style as a the configure scripts that Fabrice Bellard wrote for tcc and QEMU. They are plain ass shell scripts, beca…
eww. “Try to compile and see if it fails” is awful. I have never and would never do that. That’s so gross.
Re: Autoconf makes me think we stopped evolving too soon
#18There are super common scenarios with Autoconf, CMake, et al. which are just not provided as readily available examples or recipes and the whole time you work in these ecosystems you’re scratching your head asking why the hell no one has written these things in literal decades.
No, I’m not switching build systems because everything people use as dependencies for Real Work™ relies on you using the incumbents.
They don’t provide those templates either, anyway. Mind boggling.
Re: Autoconf makes me think we stopped evolving too soon
#19A huge part of the problem is relying on the system. Project repos should include their dependencies. The Linux model of global shared libraries is, imho, bad and wrong. Building a project shouldn’t be complicated. There should be extremely minimal branching and if checks. My blog post where I argue this in more detail: https://www.forrestthewoods.com/blog/dependencies-belong-in-...
vcpkg, conan, and Fetch_Content fix all the issues you discuss in that blog with the added benefit of not being insane. You dismiss package managers out of hand and you shouldn't.
Re: Autoconf makes me think we stopped evolving too soon
#20Portability. A test to get the answer to "what the fuck am I running on and what does it support" is more portable and robust than thousands of "flavours" manually configured in /etc/whatamieven.conf The author misses that the buildtime magic for the xz exploit is not in the m4 file but in an obfuscated, compressed, encrypted, binary disguised as a test file that alters the build process at multiple stages (configure…
configure is a mistake. Building a project shouldn’t generate input files that are dependent on the system state. That’s what C projects from the 90s do and it’s genuinely awful.