Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Autoconf makes me think we stopped evolving too soon

rachelbythebay.com

Post reply on HN
Print view View original

41–50 of 169 posts

Re: Autoconf makes me think we stopped evolving too soon

#41

Post by naasking »

forrestthewoods wrote: post #33
stonogo wrote: post #27

Earlier quoted context omitted.

It's literally the only way to be absolutely certain a specific feature is available. Version checks, shibboleth strings like __GLIBC__, documentation, all of these things can be subverted or lied to. In the end, verifying the desired behavior is present is the only correct move.

In 17 years of professional dev I have never, ever worked on a project that required such dark arts. glibc is a special evil. zig, which can compile C/C++, solves that conundrum. Hopefully someday the core glibc project fixes itself. Food for thought: cross-compile should be a first class feature of any build system. If you’re depending on a pile of arbitrary system state you’re doing it wrong. zig can compile for an…

Zig definitely has the right approach, but it's targets are still a bit limited so saying it's not difficult is maybe ignoring gcc's extreme portability that zig hasn't yet had to deal with.

Re: Autoconf makes me think we stopped evolving too soon

#42

Post by nalllar »

nickelpro wrote: post #19
forrestthewoods wrote: post #14

A 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.

conan makes it very hard to build a project offline and with a fixed set of inputs, it makes things worse in important ways if you care about reproducibility.

Re: Autoconf makes me think we stopped evolving too soon

#43

Post by jonstewart »

forrestthewoods wrote: post #14

A 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-...

Ah, the bad old days, when we checked DLLs into our cvs repos and every six months the greybeard on the team would bring a case of Mountain Dew into the office on a weekend and try upgrading the dependencies, sometimes successfully, before everyone else would arrive at work on Monday morning. Fun stuff.

Re: Autoconf makes me think we stopped evolving too soon

#44

Post by marcus_holmes »

forrestthewoods wrote: post #14

A 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-...

Ahh the eternal cycle of static vs dynamic linking swings around again.

"I need common.lib, it gets linked into my application at compile-time"

"why does every binary include this common.lib code? Let's pull that out to a shared module so we only have one version of it! See? that saved 35739475749Kb of storage! Everything is smaller and sleeker now!"

"which version of common.lib does this application need? Hmm, but that other application needs an older version. I'll have to hack some way of having multiple versions of the common.lib available"

"ahh, this application needs version 5.2.1 but that dependency needs version 4.11.6! Two incompatible versions in the same application! Who designed this thing?"

"right, let's compile whatever versions of common.lib we need into our binary. It'll make life easier and to be honest there are so many versions of common.lib around that we might as well have a separate version for every application"

"Ah, small problem, I have to compile a binary for my application for each variant of each platform because common.lib actually varies per platform... hmm, wonder if I can link to the system version of that lib at run-time..."

Re: Autoconf makes me think we stopped evolving too soon

#45

Post by dilyevsky »

jonstewart wrote: post #10
mid-kid wrote: post #4

You 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)…

> Bazel's obviously a terrible Google project and won't work if you're not sufficiently Googly

I don’t even know what that means, sounds like a bunch of fud to me. C++ and Java are first-class languages in Bazel. It works great for these, then Go, then you start venturing into the alpha land

Re: Autoconf makes me think we stopped evolving too soon

#46

Post by k8svet »

titzer wrote: post #32

Autoconf is one of the absolutely hilarious things about UNIX. On the one hand, we've got people optimizing kernels down to the individual instructions (often doing very unsafe dirty C tricks underneath), sometimes with super-clunky and overly complex APIs as a result...and on the other hand you have all the shell script absolute nuttery like the behemoth heap of kludges that is autoconf. It's crazy to me the disconn…

> scripts and autoconf and all that stringly-typed pipe stuff, ended up becoming (IMHO) the most reusable, pluggable programming environment yet devised...

I mean yes, but also only because the rest of computing is stuck in the same era. Meanwhile I'm over here popping nix-shells having my nice exact same nushell on every machine I could possibly want it on.

IMO it's all symptoms of the same problems. Related, I don't know how people start new projects and use autotools. But then again I'd say the same about cmake. But then again I just yesterday read a nightmare Lobsters comment about the realities of meson at the edges. And then I just sigh, thankful that I'm a Rust hipster (and then deal with cmake at the edges all the same). Computers are fun!

Re: Autoconf makes me think we stopped evolving too soon

#47

Post by ajross »

evmar wrote: post #11

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...

Yeah, this autotools thing is just a chance for people to whine about a favorite hated technology[1]. Clever attackers (and this was a very clever attacker) can hide stuff in anything. Anyone who thinks that CMake or Bazel or Python or whatever can't hide misbehavior is just fooling themselves.

[1] And even then it's more hatred of M4 than it is anything in autoconf per se.

Re: Autoconf makes me think we stopped evolving too soon

#48

Post by stonogo »

forrestthewoods wrote: post #33
stonogo wrote: post #27

Earlier quoted context omitted.

It's literally the only way to be absolutely certain a specific feature is available. Version checks, shibboleth strings like __GLIBC__, documentation, all of these things can be subverted or lied to. In the end, verifying the desired behavior is present is the only correct move.

In 17 years of professional dev I have never, ever worked on a project that required such dark arts. glibc is a special evil. zig, which can compile C/C++, solves that conundrum. Hopefully someday the core glibc project fixes itself. Food for thought: cross-compile should be a first class feature of any build system. If you’re depending on a pile of arbitrary system state you’re doing it wrong. zig can compile for an…

Congrats on the clean living, but it remains the norm regardless. Both CMake and Autotools use this approach.

C and C++ aren't the only languages for which this is true, by the way. It is de rigueur these days to have versioned releases for the purposes of feature gating, but there's half a century of code out there written in languages without that, and explicit feature testing will be with us as long as that code is.

Anyway, native cross-compilation is also not a language feature. Plan 9's C compilers can target any supported architecture from any other supported architecture with no special configuration.

Autotools, CMake, and "compile and see" are all artifacts of a highly diverse unix ecosystem. Tools like it are the price we pay for heterogeneity. Flexing to accomodate so many subtly different platforms is a big part of what brought things like GNU and llvm to promenence, so it's not a good idea to dismiss it as a bad thing.

Re: Autoconf makes me think we stopped evolving too soon

#49

Post by chubot »

technion wrote: post #40
chubot wrote: post #7

A 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…

Djb followed this with email and Djbdns having config scripts that were plain bash. I remember at the time a lot of people got upset - "it can never be portable". But it compiles and runs everywhere it's supported maybe we're OK with not having detection for amigaOS or something.

All the good programmers use plain shell -- DJB, Fabrice Bellard, Xavier Leroy for OCaml, etc. :)

They don't copy and paste stuff they don't understand

(The DJB scripts were almost certainly plain sh and not bash, since I think this machines were BSD. At that time bash wasn't so ubiquitous -- there was more diversity in shells. I did read a bunch of his scripts many years ago.)

Re: Autoconf makes me think we stopped evolving too soon

#50

Post by bradfitz »

Obligatory mention of this book title:

Die GNU Autotools https://a.co/d/bQyvEYm

And classic tweet: https://x.com/timmartin2/status/23365017839599616?s=46 ... "I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German."

Post reply on HN