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

151–160 of 169 posts

Re: Autoconf makes me think we stopped evolving too soon

#151

Post by parasti »

kergonath wrote: post #128
parasti wrote: post #98

Autoconf has never really made sense to me in the last twenty years or so. At what point does a Makefile-based project start thinking "hmm, we should upgrade to autoconf to solve this"? And what is "this" that they can't solve any other way? Seems like that point never occurs anymore. Either projects start with autoconf or they don't.

To me, the point is when something I write has tor each for BLAS or LAPACK and every single user seems to want it to work with a different library (ATLAS, OpenBLAS, MKL, Accelerate.framework, vanilla BLAS, cuBLAS)… Then, combine that with the various FFT libraries flavours, wherever the fuck hdf5 and NetCDF are, and which goddamned version of MPI they want to use. Not mentioning some computers where they insist on us…

That's a valid use case. Your users operate in their own diverse environments and you explicitly want to support them where they are.

Re: Autoconf makes me think we stopped evolving too soon

#152

Post by NoGravitas »

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.

Re: Autoconf makes me think we stopped evolving too soon

#153

Post by NoGravitas »

stonogo wrote: post #140
forrestthewoods wrote: post #81

Earlier quoted context omitted.

> it remains the norm regardless. Both CMake and Autotools use this approach Yes, it is the norm (in certain circles, but not others). No, it doesn't have to be that way. CMake and Autotools are both genuinely awful. The world would be a better place if Bazel/Buck2/similar were the norm. I find it extraordinarily bizarre how defensive Linux people get when I say "the status quo is actually bad, but it doesn't have to…

I didn't say Autotools and CMake weren't awful, I said that approach exists for a reason. You seem not to understand; maybe it's my poor communication skills. And I don't appreciate being called "Linux people," because I am not one, thanks. Not sure why personal attacks are in play here. The thing you're missing is that Bazel, Buck2, Zig, and all these things that do not require the compile-testing approach is they a…

Yeah, it's definitely a Chesterton's Fence problem; GP is dismissing Autotools because he has never had to deal with the problem which Autotools solves.

Re: Autoconf makes me think we stopped evolving too soon

#154

Post by db48x »

darnir wrote: post #94
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…

That's a very nice summary. But you're missing one crucial point. These are GNU tools and if you use them within that ecosystem, you also often use gnulib. Gnulib is effectively the GNU Portability Library. Your fancy, new, auto generated configure script can find all the differences, but someone still needs to account for them and write alternative code to support the various platforms. This is where gnulib comes in…

Yea, I completely forgot to mention gnulib.

Re: Autoconf makes me think we stopped evolving too soon

#155

Post by db48x »

NoGravitas wrote: post #149
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…

This comment should really be promoted to the top level and pinned. I wanted to write something similar, but if I had, it would have been less detailed than this.

That’s pretty kind of you to say. I feel like I could have come up with a better example though.

Re: Autoconf makes me think we stopped evolving too soon

#156

Post by kazinator »

NoGravitas wrote: post #150
kazinator wrote: post #134

One of the worst things about Autoconf is the way it is deployed in the GNU Project's own programs. Typically, GNU project programs assume that anyone working on the program (cloning the repo, looking for bugs, making changes, ...) has the Autotools installed. Not just any Autotools but the exact version the program wants. Only the "release tarball" if a GNU program contains the generated ./configure script that can…

Everything you say is technically true, but I can't remember a time when just having the latest autotools from my distribution packages wasn't sufficient to build a GNU package.

That's either a lucky coincidence, or use of a pre-generated ./configure script, not Autotools.

If you're actually running the steps to regenerate the Makefile.in from Makefile.am, and configure from configure.ac, and all that, then you run into the version or version range checks.

For instance, I have working repo of GNU Make. In the generate Makefile there are lines like:

  AUTOMAKE = ${SHELL} /home/kaz/make/build-aux/missing automake-1.16
The generated script missing is a wrapper for the program such as automate-1.16, which prints an error if it is missing. This version requirement comes from the file boostrap.conf:

  # Build prerequisites
  buildreq="\
  autoconf   2.69
  automake   1.16.1
  "
These prereuisite versions are also mentioned in configure.ac:

  AC_PREREQ([2.69])
  # [ ... ]
  AM_INIT_AUTOMAKE([1.16.1 foreign -Werror -Wall])
Literally, the Autotools source is asserting it must be processed by a certain version of the tools.

Needless to say, these lines change in the git history.

Re: Autoconf makes me think we stopped evolving too soon

#157

Post by forrestthewoods »

stonogo wrote: post #140
forrestthewoods wrote: post #81

Earlier quoted context omitted.

> it remains the norm regardless. Both CMake and Autotools use this approach Yes, it is the norm (in certain circles, but not others). No, it doesn't have to be that way. CMake and Autotools are both genuinely awful. The world would be a better place if Bazel/Buck2/similar were the norm. I find it extraordinarily bizarre how defensive Linux people get when I say "the status quo is actually bad, but it doesn't have to…

I didn't say Autotools and CMake weren't awful, I said that approach exists for a reason. You seem not to understand; maybe it's my poor communication skills. And I don't appreciate being called "Linux people," because I am not one, thanks. Not sure why personal attacks are in play here. The thing you're missing is that Bazel, Buck2, Zig, and all these things that do not require the compile-testing approach is they a…

First of all, thanks for engaging thoughtfully! The "Linux people" comment was a bit rude, sorry. If it helps it was meant as a general observation and not super targeted at you. Anyhow.

> they are not portable. it was not possible for decades.

I could be missing something, but I don't think this is true at all. The definition of "portable" can be quite fuzzy.

Supporting many different platforms is easy. Coming from gamedev the target platform list looks something like: Windows, macOS, SteamOS, Linux, Android, iOS, PS4, PS5, XSX, Switch. A given codebase may have supported another 10 to 20 consoles depending on how old it. Supporting all the different consoles is quite a bit more work than supporting all the niche nix flavors.

Building anything "new" probably requires building it at least three times. You make mistakes, hit edge causes, learn what's important, and eventually build something that's pretty good. It's a process. One perspective is "the approach exists for a reason". Another perspective is "damn we made a ton of mistakes, I really wish we knew then what we know now!".

> I said that approach exists for a reason

My core thesis here is that the reason is a bad one. It was a mistake. Folks didn't know better back then. That's ok. No shade on the individuals. But it doesn't mean it's a good design. In a parallel universe maybe the better design would have been made before a bad one. Such is life.

> They support Windows, MacOS, and Linux

Publicly. Internally Buck2 supports dozens of weird hardware platforms and OS variants. Adding support for a new hardware or OS platform doesn't have to be hard!

I swear compiling computer programs doesn't have to be hard! Build systems don't have to try to compile and see if it fails or not!

As one example, Windows handles linking a dynamic library much, much better than GCC/Clang on Linux. All you need is a header and a thin import static lib that only contains function stubs. GCC made a mistake by expecting a fully compiled .so to be available. The libc headers across all the different weird Unix variants are 99% identical. Supporting a new variant or version should be as simple as grabbing headers and import lib. Zig jumps through hoops to pre-produce exactly that. It'd be even better if libc headers were amalgamated into a single header. Two files per variant. Easy peasy.

Re: Autoconf makes me think we stopped evolving too soon

#158

Post by lispm »

chubot wrote: post #131
phoe-krk wrote: post #117

Earlier quoted context omitted.

> What about a Clojure program and a Common Lisp program? Probably a byte stream. (Ironically, S-expressions have no commonly used "exterior" interchange format) Probably because the details of S-expressions differ underneath the hood - a simple (foo ()) can mean a different thing on CL (where the second element is the symbol NIL) than on Scheme (where it is an empty list and not a symbol); also because Clojure intro…

Yeah the way I frame it is that Lisp is about "interior" composition (functions and data), not "exterior" (processes andf iles) Narrow Waists Can Be Interior or Exterior: PyObject vs. Unix Files https://www.oilshell.org/blog/2023/06/narrow-waist.html However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp? Well I guess Clojure/EDN is that, but nobody has produced a POLYGL…

> not "exterior" (processes and iles)

Common Lisp can read and write s-expressions from files. It can also compile source files and load files (both source and compiled).

The syntax for Common Lisp is standardized. Thus a lot of data may be shipped either in text or compiled files. Several implementations can also create snapshots of the runtime memory. A few domains use CL s-expressions (or a subset of that) as language syntax or as a data syntax.

Distributed Lisp applications exist, but may not use text to exchange data. For example there is a defined CORBA mapping for Common Lisp, which enabled Common Lisp software to take part in distributed software using a standard, which allows mixed language software.

Re: Autoconf makes me think we stopped evolving too soon

#159

Post by stonogo »

forrestthewoods wrote: post #157
stonogo wrote: post #140

Earlier quoted context omitted.

I didn't say Autotools and CMake weren't awful, I said that approach exists for a reason. You seem not to understand; maybe it's my poor communication skills. And I don't appreciate being called "Linux people," because I am not one, thanks. Not sure why personal attacks are in play here. The thing you're missing is that Bazel, Buck2, Zig, and all these things that do not require the compile-testing approach is they a…

First of all, thanks for engaging thoughtfully! The "Linux people" comment was a bit rude, sorry. If it helps it was meant as a general observation and not super targeted at you. Anyhow. > they are not portable. it was not possible for decades. I could be missing something, but I don't think this is true at all. The definition of "portable" can be quite fuzzy. Supporting many different platforms is easy . Coming from…

Ok, this will be my last try:

"The libc headers across all the different weird Unix variants are 99% identical."

This is both true and not applicable. The headers are nearly identical. The behaviors of the systems are not. Functions with the same name do different things, functions have different names but have slightly-incompatible shims with the name you expect, the headers have the function primitives but those functions are stubbed to NOPs in the actual library, and a million other things. These differences, furthermore, are not documented. All of the platforms you listed are meticulously documented and many of them have SDKs available. This, again, is not something that existed for many decades.

If libc headers being close were so meaningful, widevine binaries would work on musl libc. They do not. Modern build systems work around these incompatibilities by declaring incompatible platforms unsupported and ignoring them. That's a perfectly valid business decision that makes everyone's lives easier! But it's not the only approach, and other approachs are valid too.

Meanwhile, if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms.

I don't really understand your point in the last paragraph. Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that.

Re: Autoconf makes me think we stopped evolving too soon

#160

Post by forrestthewoods »

stonogo wrote: post #159
forrestthewoods wrote: post #157

Earlier quoted context omitted.

First of all, thanks for engaging thoughtfully! The "Linux people" comment was a bit rude, sorry. If it helps it was meant as a general observation and not super targeted at you. Anyhow. > they are not portable. it was not possible for decades. I could be missing something, but I don't think this is true at all. The definition of "portable" can be quite fuzzy. Supporting many different platforms is easy . Coming from…

Ok, this will be my last try: "The libc headers across all the different weird Unix variants are 99% identical." This is both true and not applicable. The headers are nearly identical. The behaviors of the systems are not. Functions with the same name do different things, functions have different names but have slightly-incompatible shims with the name you expect, the headers have the function primitives but those fu…

Thanks for keeping it going.

> if you want complex software to accurately and correctly support a broad array of platforms, you use Autotools to compile-and-see what behavior you're dealing with, and then something like libtool to polyfill the differences. Doing this is not the result of ignorance, but the result -- borne of hard experience -- of trying to get code working on divergent undocumented platforms.

Yes, when you have differences in behavior you need to create an abstraction layer that behaves in a single, unified way.

"The Right Thing" is to do that once ever for a given target. Write a bootstrap tool if you want. Or let one person spend one week testing and implementing shims for a brand new platform. Which is what you need to do anyways for embedded platforms that can't host the compiler. In any case don't force every user to run overly complex and brittle scripts when the result never changes for a given target.

Oh hey, this is exactly what the source article argues! At least I'm not alone.

> Neither GCC nor Clang handle linking. GNU ld or gold or some linker is invoked to do that.

Bleh. ld is part of the GNU toolset. Pretend I said "standard Linux linking behavior". As you said, Linux's popularity stems from a collection of tools that work together nicely. The point I tried and failed to make is "compiling and linking doesn't have to be hard". Implementing an abstraction layer for a new platform isn't particularly hard either. Probably best to forget I said it.

> this will be my last try:

Thanks for the chat!

Post reply on HN