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

31–40 of 169 posts

Re: Autoconf makes me think we stopped evolving too soon

#31

Post by senectus1 »

jauntywundrkind wrote: post #2

This goes opposite of how I think of evolution. 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 overl…

also... what makes them think we stopped evolving?

much like history, you don't actually notice it till after its done :-P

Re: Autoconf makes me think we stopped evolving too soon

#32

Post by titzer »

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

And, oh by the way, underneath? Shells have some of the absolutely bonkersly dumb parsers and interpreters; absolutely embarrassingly dumb stuff like aliases that can override keywords and change the parsing of shell script. The fact that some (most) shells interpret a shell script one line at a time, and that "built-ins" like the syntax for conditions in ifs looks like syntax but might be little binaries underneath (look up how "[" and "]" is handled in some shells--it might not be!).

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

Re: Autoconf makes me think we stopped evolving too soon

#33

Post by forrestthewoods »

stonogo wrote: post #27
forrestthewoods wrote: post #17

Earlier quoted context omitted.

eww. “Try to compile and see if it fails” is awful. I have never and would never do that. That’s so gross.

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 any target from any target. It’s beautiful. And not nearly as difficult as people seem to think.

Re: Autoconf makes me think we stopped evolving too soon

#34

Post by opello »

elicksaur wrote: post #25

Is anyone doing and publicizing the git clone vs. tarball work in other projects? I suppose if something has been found, it might be too soon to disclose publicly.

The major downside of using git clone build workflows from an autotools project is that your build environment and the developer's may have different enough versions of autotools that macro incompatibility introduces more problems for you to solve. I've noticed this less recently (say 5 years) but still has come up occasionally. While a distributed tarball will have the "developer blessed" autoreconf run and declared good by way of releasing the tarball.

Without that process the options are committing generated files (boo) and burdening those that would build from a git clone instead of a distribution tarball with the demands of details from the development environment. That's intentionally a little vague because of the variety of things that can ultimately affect the autotools output.

All of this is kind of the design of the autotools build process and could very well be a reason to take a harder look at it and the tradeoffs incumbent on its use.

Re: Autoconf makes me think we stopped evolving too soon

#35

Post by jonstewart »

amluto wrote: post #23
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)…

libtool does serve a purpose: it causes plain 'make' to produce shell script wrappers as outputs, which is maybe kinda sorta vaguely useful when developing and utterly and completely obnoxious if you want an actual ELF file. So you end up running 'make install' when you didn’t actually want to install or trying to remember how to find the actual ELF files. And you then wonder why 'make install' appears to be building…

Oh right, how could I forget that awful aspect of using libtool? I hate my life; maybe 2024 will be the year I find a decent build tool and the motivation to move projects to it.

Contra your slight defense, is it really so hard to produce a good DSO these days? -fPIC is half the battle and a couple other weird flags for macOS/darwin will do you. Cross-compiling for Windows, sure, a few more flags — but you look them up once on stackoverflow, you have three options, and you're done.

Re: Autoconf makes me think we stopped evolving too soon

#36

Post by nabla9 »

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…

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.

Re: Autoconf makes me think we stopped evolving too soon

#37

Post by jonstewart »

jeremyjh wrote: post #24
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)…

I don't know how you can think CMake is worse than autoconf. At least it has a declarative approach with good mechanisms for reusing common logic. Its much easier for IDEs/editors to work with it.

I don't think it's worse, per se, but I hate it/myself _more_ when I contemplate switching from autotools to cmake -- it's like upgrading from CP/M to DOS, when what I'd like to have is a Mac.

And as much as autotools blows, every time I try to build some project that uses cmake I inevitably go through some rigmarole making a build directory (not that out-of-source tree builds aren't the right thing, they are, but why make me create one?) and finding some obscure set of -D options to get the sucker to build on my system. configure && make still has cmake beat from a user's perspective.

Re: Autoconf makes me think we stopped evolving too soon

#38

Post by forrestthewoods »

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.

> not being insane

Insane? It’s what all of BigTech and every game dev does. It’s tried and true.

> vcpkg, conan, and Fetch_Content fix all the issues

Not really, no.

Re: Autoconf makes me think we stopped evolving too soon

#39

Post by oefrha »

chubot wrote: post #8
smackeyacky wrote: post #6

Earlier quoted context omitted.

If you're building something really portable, you still need autoconf. Anything that has to run on a BSD or a Mac needs these tools. 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…

Anything that has to run on a BSD or a Mac needs these tools 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 lin…

QEMU and tcc were created by Fabrice Bellard, they were written by a god! Us mortals use autoconf ;)

Re: Autoconf makes me think we stopped evolving too soon

#40

Post by technion »

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.
Post reply on HN