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

161–169 of 169 posts

Re: Autoconf makes me think we stopped evolving too soon

#161

Post by marcus_holmes »

forrestthewoods wrote: post #85
marcus_holmes wrote: post #44

Earlier quoted context omitted.

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

> Ahh the eternal cycle of static vs dynamic linking swings around again. Somewhat. Although it's agnostic to static vs dynamic linking. The philosophy goes a bit deeper than that. > See? that saved 35739475749Kb of storage! Storage capacity hasn't been relevant for over a decade. Besides, we foolishly replaced "use shared modules to save storage space" with "build multi-gigabyte docker images because it's the only w…

Storage capacity was relevant in an earlier iteration of the cycle, I apologise for making that point so clumsily.

Re: Autoconf makes me think we stopped evolving too soon

#162

Post by chubot »

lamontcg wrote: post #147
chubot wrote: post #144

Earlier quoted context omitted.

What's different about Oils is that it's compatible with both /bin/sh and bash. https://www.oilshell.org/blog/2021/01/why-a-new-shell.html https://www.oilshell.org/blog/2023/03/faq.html OSH should be trivial to use on Solaris/AIX -- all you need is a C++ compiler and /bin/sh, no make tool even. https://www.oilshell.org/blog/2023/12/screencasts.html#appen... But if everyone on Linux and BSD uses bash/OSH, and Solaris…

Sure but the problem is that Solaris/AIX will be very slow to actually install it, so you can't count on it being there, and those distros DO influence things like autoconf and configure scripts. And people who run them pay big money contracts to get those distros supported (one bank contract for support is worth much more than 10,000 linux users who don't pay anyone a dime). The inertia is very real, bigger than you…

Shell is used A LOT -- for data science, machine learning, cloud, CI, putting together Linux distros / boostrapping, embedded systems, and other heterogeneous problems.

configure is one use case. And autoconf in particular will probably be around forever, regardless of the existence of Solaris/AIX -- for the simple reason that many old and important packages like coreutils use autoconf.

Probably nobody is going to rewrite the coreutils build system soon. (coreutils might be rewritten/obsolete before that happens!)

The good news is that OSH can run configure scripts as-is :) It's actually easy to run them, because they are meant to run on many different shells.

---

It's also not a binary yes/no thing. Cobol and Fortran aren't dead, but people choose to write new projects in different languages now, and that's good! I had an entire career without seeing any Cobol at all. Zero.

Likewise OSH can run POSIX configure scripts forever (and those same configure scripts can be run by /bin/sh and bash)

But I think lots of people will choose to write brand new YSH scripts as well.

The computing world is only getting more heterogeneous (in both time and space). Shell accomodates that, and Oils is designed to accomodate that.

Re: Autoconf makes me think we stopped evolving too soon

#163

Post by xcrunner529 »

db48x wrote: post #28
thechao wrote: post #13

Earlier quoted context omitted.

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 !?

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 seems more, then, that devs need to just move on from gross C (and C++?) at this point to modern mandates without all this insecure baggage and constant security issues from lack of memory management.

Re: Autoconf makes me think we stopped evolving too soon

#164

Post by xcrunner529 »

ajross wrote: post #127
kergonath wrote: post #125

Earlier quoted context omitted.

> And even then it's more hatred of M4 than it is anything in autoconf per se. To be fair, M4 is rather…special. And when you add that in a Makefile template with shell thrown into the mix it gets _very_ hairy.

Oh sure, and that's true enough. Working with autoconf[1] is a giant pain for Kids Today weaned on entirely different idioms[2]. And it's the kind of thing you can't really avoid[3] if you're going to be doing work on these traditional Linux packages. And that sucks, and it makes it look like Linux is a weird kingdom filled with dinosaurs. And that sucks because you still have to work in Linux. So you hate the proxim…

Because so much of the Linux world refuses to let C go.

Re: Autoconf makes me think we stopped evolving too soon

#165

Post by lelanthran »

forrestthewoods wrote: post #148
lelanthran wrote: post #93

Earlier quoted context omitted.

Okay, what's the alternative when `accept` has three parameters when using glibc and two parameters when using musl?[1] How else do you determine which one to use other than by compiling against the chosen library and seeing what fails? [1] just an example, musl mighy actually have same amount of parameters as glibc for all I know. But newlib doesn't.

The build system should specify whether it wants glibc or musl and what version. Relying on current system state is one of the reasons that glibc is such a monumental pain in the ass. It should be trivial to target an arbitrary version of glibc. (zig build system achieves this). The way C projects from the 90s work is you locally run .configure and it generates a whole bunch of headers, if not .c files, with a whole…

> Relying on current system state

Autoconf is most useful when the build isn't relying on current system state! That's it's most useful characteristic. If the goal was to build against the current system, autoconf probably would never have existed. Building against the current system is a side-effect of doing proper cross-compilation builds.

> "The Right Thing" is for the repo files to contain a superset and for the build system pass the tiny handful of defines necessary to select the target platform. For example glibc, musl, PlayStation4, NintendoSwitch, etc.

For common platforms, sure... that works well and that is sort of how my Makefiles are written.[1]

But to cover the domain that autoconf/configure.sh covers ... well that is not feasible. Glibc might have 3 parameters when compiling against Linux, but 2 when compiling against Solaris. Linux itself might have some `#define`s when compiling on x86_64, and a different set when compiling on RISC-V. The target distribution might have different parameters when compiled for Debian vs when compiled for Alpine.

It's why gcc uses hyphenated targets: `ISA`-`kernel`-`platform`. So you see things like `x86_64-w64-mingw32` and `sparc-unknown-linux-gnu`. The combinatorial explosion of ISA + kernel + ABI + distro + user libs is much much harder to manage for a portable project that has many dependencies than simply putting up with autoconf.

I mean, I don't even like autoconf (which is why I avoid it), but I gotta say, autoconf actually does solve those problems especially for cross-compiling, because then the entire chain of libraries getting linked in will be guaranteed to be the correct ones, for the correct ABI, on the correct target ISA, on the correct target kernel, on the correct target distribution ... and if something doesn't match, you'll know before Make is even run. This is especially important with C++, which needs another value in the tuple for seh/sjlj, and you cannot detect which of the two you need until you run the resulting program and it generates an exception.

It's just possible that, in 2024, we don't actually need the level of portability that autoconf brings to cross-compilation anymore - build it against Windows/Linux/BSD on x86_64/ARM and you cover about 50% of useful scenarios.

Those that need the remaining 50% probably already know what they are doing and can tweak the Makefiles and/or source code to build for their target.

[1] I do minimal detection and expect the user to set certain variables if they don't want the defaults.

Re: Autoconf makes me think we stopped evolving too soon

#166

Post by forrestthewoods »

NoGravitas wrote: post #152
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-...

I, too, enjoy rebuilding the world from source when there's a security issue found in a commonly-used dependency.

You mean all your docker containers, right?

Re: Autoconf makes me think we stopped evolving too soon

#167

Post by cout »

dima55 wrote: post #96
cout wrote: post #89

Earlier quoted context omitted.

I just write (gnu) makefiles for my projects these days and invoke pkg-config to detect libraries and features. It's easy for me because I've been doing it this way for decades. But there are way too many footguns for me to recommend it to new developers (although I'm not sure what I would recommend instead either).

I think Make is exactly what you want, and I do recommend it to everybody, since the default alternative is usually something heinous like CMake which isn't really an improvement. You want the bit of logic to create a "build system" out of Make abstracted into a library, and then it's perfect. I use this: https://github.com/dkogan/mrbuild/ but there're many other ways to do it

What I want is a DAG, but with better syntax than make.

The closest I have come to ideal is a custom ninja build file generator, which is pretty simple. It's been easier for other people to maintain than make or even rake.

Re: Autoconf makes me think we stopped evolving too soon

#168

Post by egberts1 »

jonstewart wrote: post #16
thechao wrote: post #13

Earlier quoted context omitted.

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

Unfortunately, pkg-config couldn't handle C++ files nor the transition from lib32 to lib64; as Captain Kirk heard from Bone: "he's dead, Jim".

Re: Autoconf makes me think we stopped evolving too soon

#169

Post by jeremyjh »

jonstewart wrote: post #37
jeremyjh wrote: post #24

Earlier quoted context omitted.

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

Yeah it’s not intended to be used directly for end user builds. Its ultimate product is a set of makefiles (or Visual Studio project files) and the developer should distribute those.
Post reply on HN