Autoconf makes me think we stopped evolving too soon

Admittedly, my feels are that we socially tend to overly emphasize the brutalist shades of Darwinianism, of natural selection as a competitive pressure.

Evolution though is a much broader game of adaption, of finding niches. It's about capturing energy. And having diverse & creative means to adapt & succeed, less one finds oneself trapped only able to survive in a overly narrow environment. Evolutions greater story is more about over specialization being doom than it is about refining the exact perfect match; the perfect matches are amazing & elegant but rarely able to stick around.

I don't really know my stance here. But it does feel like a call for authority. Why are we still diverse? Why still have complexity? Can't someone free us of the diversity of options and crown a champion, decree how it will be? That sort of resembles Darwinianism on the small, but in the big, we get change & evolution from having non-static environments, from having many ways to shape and be shaped, all about.

That shift from dynamic to static systems, when evolution peaks, is usually not far from when that stasis turns to ossification & rot, decay & the fall. We probably should cleanup some & not support a million options, for our own sake, but this notion the past had of supporting a deeply rich & diverse technical ecosystem I find enormously beautiful.

Anyhow, I forget how often autoconf needs to be run. I think often many projects would work fine for aomg time using the same generated conf across many many builds? There's focus here on the silliness of re-running config again and again and again, but I'm not sure when technically it's required; it seems more like habit & ritual than a need?

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]: https://www.gnu.org/software/autoconf/manual/autoconf-2.65/h...

The article comes across as a bit of "blame the tools" where the tools aren't really at fault, it's the culture which has failed here. We seem to have never graduated from "wow it actually works" levels of Linux appreciation that isn't that different from the 1990s. Those distributions that most of us rely on (whether directly or indirectly) - Debian, RHEL - need to up their game somehow on vetting the packages they accept.

We also need to stop just downloading .deb packages from the internet and installing them and preferring distros that look at security as a serious business including the packaging.

Blaming autoconf is just silly. Sure it can be annoying, is mired in the past and perhaps seen as an anachronism now. But it's not to blame for supply chain attacks any more than a C compiler can be blamed for supply chain attacks.

Do QEMU, tcc, and OCaml run on BSD and Mac? Pretty sure they do

https://news.ycombinator.com/item?id=39925033

https://github.com/lucasaiu/ocaml/blob/master/configure

They have hand-written configure scripts, and don't use autoconf.

---

Also, https://www.oilshell.org/ runs on BSD and Mac, and it doesn't use autoconf. The configure script is a few hundred lines of "boring" shell.

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) you wind up running configure all the time. This is because, most probably, your Makefile.am lists every source file individually. If you add a new source file, you must rerun autoreconf to regenerate your Makefile — and that also generates configure anew. Then the Makefile sees that configure is newer than config.h (or some other output, I don't want to look up the gory details) and, blammo!, when you run make, first configure runs.

Of course with git, this happens not just when you add a new source file to your project... it happens whenever you switch branches, where there's variance in the source files in the project. configure configure configure configure.

As much as I hate it, autoconf isn't the worst part of autotools. Automake is... pointless? Is it really less effort to write Makefile.am than to write a straight Makefile? Wouldn't that be simpler?

And then there's libtool, which should be drug out into a back alley and executed. A 2000 LoC shell script, whose whole purpose in life is to figure out, over and over and over again, stateless in the same way as TFA complains about with autoconf, precisely which compiler flags should be used to build a shared library on a system amongst all the old compilers, even though today everyone just uses gcc and clang, which are flag-compatible, and determining which flags to use is not really that hard. Please, someone, anyone, please kill libtool and banish it from this earth.

I tried Meson — ran into a problem, read the docs, asked a question on the mailing list, never got an answer, never got past it. Bazel's obviously a terrible Google project and won't work if you're not sufficiently Googly. Cmake, a disaster. I liked tup, but it seems to have died (and it didn't solve the autoconf problem anyway).

Which new build system will deliver us from the 18th circle of hell? (probably cargo, as the Rust fanbois work to get C/C++ deprecated...)