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

71–80 of 169 posts

Re: Autoconf makes me think we stopped evolving too soon

#71

Post by pas »

wyldfire wrote: post #60

I'm finding myself in the unenviable position of defending autotools. > They were a reflection of the way the kernel, C libraries, APIs and userspace happened to work. Short of that changing, the results wouldn't change either. These things do change, especially as toolchain and OS vendors realize their quirks that cause portability friction.

there's absolutely nothing wrong with the functionality (it's essential in fact), it's that maybe, maybe, we should purge shell scripts from our hearts. (or at least reserve them for ad-hoc one-off in-situ time-conscious pragmatic programs, instead of letting a billion bash-lines beat its little shell-song behind every .deb,.rpm & etc.)

// and of course 'should' is more like "it would be great if someone would rewrite it in Rust"

Re: Autoconf makes me think we stopped evolving too soon

#72

Post by drekipus »

chubot wrote: post #52
nabla9 wrote: post #36

Earlier quoted context omitted.

Alan Perlis Epigram #9: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." Unix settled for string as a data structure and it's little too low level. All Lisp programmers know that s-expressions would have been the right choice. JSON works also.

Yup, I call that the Perlis-Thompson Principle -- because Ken Thompson made a similar combinatorial argument about software composition: you should design it around "one thing". https://www.oilshell.org/blog/2021/07/blog-backlog-1.html#co... Files had structure on pre-Unix OSes, but they don't on Unix, because it doesn't compose. The "Uniform Interface Constraint" of REST is the same thing, and resembles a file syste…

What benefit is this?

I mean, I love the look of it, but how can it help me from day dot?

Re: Autoconf makes me think we stopped evolving too soon

#73

Post by pianoben »

dilyevsky wrote: post #45
jonstewart wrote: post #10

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

> 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

Works great if you follow Google's style of vendoring all of your dependencies. If you try to rely on third-party package managers like Maven or Ivy or whatever C++ uses, you're in for some serious pain. The more you venture into OSS tools like Spring, gRPC, containers, the more you have to incorporate shoddy and poorly-maintained third-party Bazel tools which inevitable stomp on each other in subtle ways.

My team abandoned Bazel for Gradle, and it has been a tremendous quality-of-life improvement.

Re: Autoconf makes me think we stopped evolving too soon

#74

Post by bee_rider »

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

We should just write Makefiles. If you want to be really nice, have it source a Makefile.inc file and keep all the user configuration stuff in there. If you want to be really really nice, consider accepting pull requests for .inc files that work with popular distros.

Re: Autoconf makes me think we stopped evolving too soon

#75

Post by pianoben »

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

I can't tell what the disabling element is - is it the variable rename from HAVE_LINUX_LANDLOCK_H to HAVE_LINUX_LANDLOCK? That seems the most suspicious to me, an uneducated bystander. Or, does the snippet just never compile?

Re: Autoconf makes me think we stopped evolving too soon

#76

Post by evmar »

pianoben wrote: post #75
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...

I can't tell what the disabling element is - is it the variable rename from HAVE_LINUX_LANDLOCK_H to HAVE_LINUX_LANDLOCK? That seems the most suspicious to me, an uneducated bystander. Or, does the snippet just never compile?

8th added line in the patch has a stray period

Re: Autoconf makes me think we stopped evolving too soon

#77

Post by smackeyacky »

cpeterso wrote: post #53
db48x wrote: post #28

Earlier quoted context omitted.

In decades past, if you were developing software for Unix you would inevitably run across compatibility problems. Even with the POSIX standard, every Unix was trying new things, inventing new things, or just implementing the same thing in slightly different ways. So your programs had to have a bunch of macros to switch between different variations. Some API would have two arguments on Unix A but three on Unix B, so y…

It always seemed to me that most of these differences and macros could be defined in a static header file that has a million #ifdefs for different OS and compiler versions. That seems simpler and more reliable, and usable for cross compiling, than running dynamic checks with autoconf.

Hmmm. Nope. The file would be near unusable and contain a pile of things you don’t care about where autoconf can cope with the one or two cases you are trying to manage.

Despite the description above of the genesis of autoconf, at the time when there were dozens of nearly compatible unices, it was a key enabling technology for free software to be distributed and shouldn’t be discounted just because it’s a little hard to understand.

Re: Autoconf makes me think we stopped evolving too soon

#78

Post by forrestthewoods »

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…

> What a wild irony that all the ickiest parts of UNIX--shells and scripts and autoconf and all that stringly-typed pipe stuff, ended up becoming (IMHO) the most reusable, pluggable programming environment yet devised...

I increasingly believe any shell script over ~128 “symbols” should be re-written in a “real” programming language.

I’ll gladly take a slightly longer Python, Go, or Rust “script” over Bash hell every day of the week.

Re: Autoconf makes me think we stopped evolving too soon

#79

Post by pianoben »

evmar wrote: post #76
pianoben wrote: post #75

Earlier quoted context omitted.

I can't tell what the disabling element is - is it the variable rename from HAVE_LINUX_LANDLOCK_H to HAVE_LINUX_LANDLOCK? That seems the most suspicious to me, an uneducated bystander. Or, does the snippet just never compile?

8th added line in the patch has a stray period

Wow! It looks obvious when you point it out, but I'd stared for probably 10 minutes and likely would never have noticed it.

Re: Autoconf makes me think we stopped evolving too soon

#80

Post by Too »

bee_rider wrote: post #74
jonstewart wrote: post #10

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

We should just write Makefiles. If you want to be really nice, have it source a Makefile.inc file and keep all the user configuration stuff in there. If you want to be really really nice, consider accepting pull requests for .inc files that work with popular distros.

Makefiles are too brittle and allow all kinds of user errors. Targets with too many dependencies, too few dependencies, race conditions. The default doesn’t even handle transitive #include dependencies without you yourself plugging in complex .d-file generation using the compiler.
Post reply on HN