6 ms·

What autoconf got right

71 points by WhyNotHugo 2y ago

endgame 2y ago
This is a great list, and it's good to see a counterpoint to the autobashing that's trendy these days. One additional point: autotools are bootstrappable without going all the way up to C++ (CMake, ninja) or Python (meson). And yes, muon and samurai are written in C99, but as soon as I wanted to both support -fvisibility=hidden and unit tests in my project, I was forced to build both static and shared libraries. This forced me back onto libtool, and once I was there I figured I may as well stick with the good ol' autotools.
- RcouF1uZ4gsC 2y ago
  > One additional point: autotools are bootstrappable without going all the way up to C++ (CMake, ninja) or Python (meson). GCC is written in C++. So on a modern system you are going to have to use C++ anyway.
  - uecker 2y ago
    People work on bootstrapping with GCC 4.8 which is still C.
- page_fault 2y ago
  A large chunk of meson functionality is supported by muon, which is a pure C implementation with no dependencies. I tested it for fun with several projects and it was indistinguishable from "proper" meson. Haven't tried with anything large like qemu or systemd, though. https://muon.build https://muon.build
  - endgame 2y ago
    I tried to use muon once and immediately discovered that it rejects passing a dict to the project() function, does not support cross-compilation, and a few other things I consider important. I hope it continues to close the gap. But also, I still don't have an answer to "I want to build with -fvisibility=hidden and also have unit tests" that isn't "libtool".
    - mid-kid 2y ago
      Last I checked meson supports unit testing shared libraries just fine, as well as building both static and shared libraries "both_libraries()". This integrates fine with testing, though it modifies the binaries' rpath for library search instead of wrapping them in a script like libtool does.
      - endgame 2y ago
        Even if you build your shared objects with -fvisibility=hidden?
- throwaway2046 2y ago
  >One additional point: autotools are bootstrappable without going all the way up to C++ (CMake, ninja) or Python (meson). You do need Perl though.
  - deleted 2y ago
    [deleted]
IshKebab 2y ago
Not very much then... Tbh I think the existence of "packager" as a distinct job is a huge failing of the Linux software ecosystem. As is the fact that 99% of Linux software defaults to hard-codes absolute paths and spewing its files all over the system, rather than installing to a single directory that you can freely relocate.
- ur-whale 2y ago
  Another one is everyone in the 90's believed shared libraries were a major innovation and therefore to be used everywhere. They turn out to be bringing fairly little benefit (minuscule disk space saving) and giant drawbacks (the vaunted "your software will be upgraded / bugfixed behing your back" which instead turned out to be a configuration nightmare and an exponential multiplication of the attack surface for would be attackers) To this day, I dread to try an run an old binary that was linked against shared libraries say 5 years ago on a modern system. Chances of it working are quasi zero, and good luck trying to reconstitute the tree of shared libraries that are recursively required to get that binary to run, glibc often being the worst offender of the lot.
  - zajio1am 2y ago
    They are. Static linking may be okay for small and simple libraries, but as a user, i do not want multiple versions of a complex library linked inside applications, each with slightly different behavior. And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype.
    - IshKebab 2y ago
      > And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype. I don't think many people have problems with the idea that core system libraries could be dynamically linked. But Linux distros take this to a ridiculous extreme. I absolutely do not care if a bug in libgmp means my package manager updates the 2 apps I have installed that use it instead of 1 library. Would be really interesting to see some actual stats about this though. How many library projects do people have installed that are depended on by more than say 3 apps? I'm guessing it's under 100. I think that's the approach Flatpak takes with it's "runtimes" and it seems like a very sensible one.
deleted 2y ago
[deleted]
38 2y ago
Good riddance. These days I download a repo and "go build". That's literally it. I used C/C++ for years, and it was always a nightmare to build something, unless it was completely self contained. When your "packaging" is so bad that everything has to be vendored, that should be a red flag.
- _mlbt 2y ago
  Another thing I really appreciate about go is how easy it makes cross compilation.
zajio1am 2y ago
I mostly agree with the list, but i think there are also some arguments what are suboptimal about Autoconf: 1) We do not need to support old buggy platforms, we can generally assume that platforms are open source and their bugs can be fixed, so it is less pressure to workaround them in application software. Consequently, we do not need that detailed checks 2) We can assume there is fully working POSIX shell, so configure script and its checks could be made just in shell, no need to have M4-generated shell code. 3) It is probably better not have separate 'release-phase', so end-users could just work with code from git. Users could run Autoconf themselves to generate the configure script, but the Autoconf is not well-suited for this, as there is lack of backwards compatibility. 4) Most developers do not know M4, so they just hack around Autoconf macros without proper understanding. 5) It would be nice if all these directories that are given to configure scripts could be overridden at runtime using environment variables Ideally, there could be POSIX shell script library that could be used to write portable configure scripts offering all the standard options and checks like ones generated by Autoconf.
- hulitu 2y ago
  > We can assume there is fully working POSIX shell, Kids those days. Haven't we learned a long time ago that we shouldn't assume anything ?
  - pornel 2y ago
    You have to set some baseline. We assume the CPU can divide numbers correctly, even though not all of them did. Autoconf has set the baseline so low that everyone perpetually pays for the technical debt of ancient buggy platforms. Sometimes it's better to push a buggy platform to fix its own bugs, than to have everyone work around those bugs forever.
  - technion 2y ago
    The issue is defining "support". I would argue it can be harmful having autoconf detect a non compliant shell and advertise it was trying to build a makefile around that fact if no one has ever tested your app on such a platform and something in the code will fail anyway.
thefilmore 2y ago
Bell Labs had a simpler alternative in IFFE [0], that consisted of a single shell script [1]. You would specify any required headers, libraries and tests in a simple text file [2]. [0] https://www.cs.tufts.edu/~nr/cs257/archive/glenn-fowler/iffe.pdf https://www.cs.tufts.edu/~nr/cs257/archive/glenn-fowler/iffe... [1] https://github.com/att/ast/blob/master/src/cmd/INIT/iffe.sh https://github.com/att/ast/blob/master/src/cmd/INIT/iffe.sh [2] https://github.com/att/ast/blob/master/src/cmd/3d/features/syslib https://github.com/att/ast/blob/master/src/cmd/3d/features/s...
jujube3 2y ago
It provides a standardized interface. This is just a long-winded way of saying it's popular. It's popular, therefore people know it, therefore they view whatever it does as "the standard." Kind of like... MS Windows? It is based on checking features. The feature-checking approach is slow and makes cross-compilation unnecessarily difficult. Plus a lot of the "features" that auto-conf checks for are things that haven't been an issue for decades, like "sizeof char"
- viraptor 2y ago
  Standardised doesn't mean popular. It means you know what --help, --enable-foo, DESTDIR, etc. will do and that you can rely on that format. It means packaging can rely on the same flow and common options for each package using autoconf. It then means that unless you've got very specific needs, your packaging can be abstracted to "here's the source, the name and the version - go!" and that's the abstraction many distros provide.
  - hnfong 2y ago
    Yes, and everyone knows what those options are, and can expect the same flow for each package because... ... autoconf is popular.
    - wakawaka28 2y ago
      You're partly right but autoconf's design is pretty rigid. I've never seen one where the install destination isn't set via one of the standard flags like --prefix. But I have seen other build systems randomize their install processes. Maybe this is a function of what kind of people use each tool. Autotools is mainly adopted by experienced geeks. Other build systems are more beginner-friendly and that might result in less appropriate solutions being written.
      - jujube3 2y ago
        Once you leave behind the simple things like --prefix, it's not that standardized. But, arguing over this is futile, this wheel has been reinvented innumerable times.
zxspectrum1982 2y ago
My main problem with autotools has never been m4 but the fact that they don't provide a good experience on Windows. Cygwin is not something you want to depend on due to performance, and while MSYS has made great strides, as of 2024 it's not yet perfect. IMHO people invented CMake and other build systems after being tired of trying to get autotools to provide a nice experience on Windows.

71 points by WhyNotHugo 2y ago

This is a great list, and it's good to see a counterpoint to the autobashing that's trendy these days. One additional point: autotools are bootstrappable without going all the way up to C++ (CMake, ninja) or Python (meson). And yes, muon and samurai are written in C99, but as soon as I wanted to both support -fvisibility=hidden and unit tests in my project, I was forced to build both static and shared libraries. This forced me back onto libtool, and once I was there I figured I may as well stick with the good ol' autotools.

RcouF1uZ4gsC 2y ago
> One additional point: autotools are bootstrappable without going all the way up to C++ (CMake, ninja) or Python (meson). GCC is written in C++. So on a modern system you are going to have to use C++ anyway.
- uecker 2y ago
  People work on bootstrapping with GCC 4.8 which is still C.
page_fault 2y ago
A large chunk of meson functionality is supported by muon, which is a pure C implementation with no dependencies. I tested it for fun with several projects and it was indistinguishable from "proper" meson. Haven't tried with anything large like qemu or systemd, though. https://muon.build https://muon.build
- endgame 2y ago
  I tried to use muon once and immediately discovered that it rejects passing a dict to the project() function, does not support cross-compilation, and a few other things I consider important. I hope it continues to close the gap. But also, I still don't have an answer to "I want to build with -fvisibility=hidden and also have unit tests" that isn't "libtool".
  - mid-kid 2y ago
    Last I checked meson supports unit testing shared libraries just fine, as well as building both static and shared libraries "both_libraries()". This integrates fine with testing, though it modifies the binaries' rpath for library search instead of wrapping them in a script like libtool does.
    - endgame 2y ago
      Even if you build your shared objects with -fvisibility=hidden?
throwaway2046 2y ago
>One additional point: autotools are bootstrappable without going all the way up to C++ (CMake, ninja) or Python (meson). You do need Perl though.
- deleted 2y ago
  [deleted]

IshKebab 2y ago

Not very much then... Tbh I think the existence of "packager" as a distinct job is a huge failing of the Linux software ecosystem. As is the fact that 99% of Linux software defaults to hard-codes absolute paths and spewing its files all over the system, rather than installing to a single directory that you can freely relocate.

ur-whale 2y ago
Another one is everyone in the 90's believed shared libraries were a major innovation and therefore to be used everywhere. They turn out to be bringing fairly little benefit (minuscule disk space saving) and giant drawbacks (the vaunted "your software will be upgraded / bugfixed behing your back" which instead turned out to be a configuration nightmare and an exponential multiplication of the attack surface for would be attackers) To this day, I dread to try an run an old binary that was linked against shared libraries say 5 years ago on a modern system. Chances of it working are quasi zero, and good luck trying to reconstitute the tree of shared libraries that are recursively required to get that binary to run, glibc often being the worst offender of the lot.
- zajio1am 2y ago
  They are. Static linking may be okay for small and simple libraries, but as a user, i do not want multiple versions of a complex library linked inside applications, each with slightly different behavior. And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype.
  - IshKebab 2y ago
    > And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype. I don't think many people have problems with the idea that core system libraries could be dynamically linked. But Linux distros take this to a ridiculous extreme. I absolutely do not care if a bug in libgmp means my package manager updates the 2 apps I have installed that use it instead of 1 library. Would be really interesting to see some actual stats about this though. How many library projects do people have installed that are depended on by more than say 3 apps? I'm guessing it's under 100. I think that's the approach Flatpak takes with it's "runtimes" and it seems like a very sensible one.

deleted 2y ago

[deleted]

38 2y ago

Good riddance. These days I download a repo and "go build". That's literally it. I used C/C++ for years, and it was always a nightmare to build something, unless it was completely self contained. When your "packaging" is so bad that everything has to be vendored, that should be a red flag.

_mlbt 2y ago
Another thing I really appreciate about go is how easy it makes cross compilation.

zajio1am 2y ago

I mostly agree with the list, but i think there are also some arguments what are suboptimal about Autoconf: 1) We do not need to support old buggy platforms, we can generally assume that platforms are open source and their bugs can be fixed, so it is less pressure to workaround them in application software. Consequently, we do not need that detailed checks 2) We can assume there is fully working POSIX shell, so configure script and its checks could be made just in shell, no need to have M4-generated shell code. 3) It is probably better not have separate 'release-phase', so end-users could just work with code from git. Users could run Autoconf themselves to generate the configure script, but the Autoconf is not well-suited for this, as there is lack of backwards compatibility. 4) Most developers do not know M4, so they just hack around Autoconf macros without proper understanding. 5) It would be nice if all these directories that are given to configure scripts could be overridden at runtime using environment variables Ideally, there could be POSIX shell script library that could be used to write portable configure scripts offering all the standard options and checks like ones generated by Autoconf.

hulitu 2y ago
> We can assume there is fully working POSIX shell, Kids those days. Haven't we learned a long time ago that we shouldn't assume anything ?
- pornel 2y ago
  You have to set some baseline. We assume the CPU can divide numbers correctly, even though not all of them did. Autoconf has set the baseline so low that everyone perpetually pays for the technical debt of ancient buggy platforms. Sometimes it's better to push a buggy platform to fix its own bugs, than to have everyone work around those bugs forever.
- technion 2y ago
  The issue is defining "support". I would argue it can be harmful having autoconf detect a non compliant shell and advertise it was trying to build a makefile around that fact if no one has ever tested your app on such a platform and something in the code will fail anyway.

thefilmore 2y ago

Bell Labs had a simpler alternative in IFFE [0], that consisted of a single shell script [1]. You would specify any required headers, libraries and tests in a simple text file [2]. [0] https://www.cs.tufts.edu/~nr/cs257/archive/glenn-fowler/iffe.pdf https://www.cs.tufts.edu/~nr/cs257/archive/glenn-fowler/iffe... [1] https://github.com/att/ast/blob/master/src/cmd/INIT/iffe.sh https://github.com/att/ast/blob/master/src/cmd/INIT/iffe.sh [2] https://github.com/att/ast/blob/master/src/cmd/3d/features/syslib https://github.com/att/ast/blob/master/src/cmd/3d/features/s...

jujube3 2y ago

It provides a standardized interface. This is just a long-winded way of saying it's popular. It's popular, therefore people know it, therefore they view whatever it does as "the standard." Kind of like... MS Windows? It is based on checking features. The feature-checking approach is slow and makes cross-compilation unnecessarily difficult. Plus a lot of the "features" that auto-conf checks for are things that haven't been an issue for decades, like "sizeof char"

viraptor 2y ago
Standardised doesn't mean popular. It means you know what --help, --enable-foo, DESTDIR, etc. will do and that you can rely on that format. It means packaging can rely on the same flow and common options for each package using autoconf. It then means that unless you've got very specific needs, your packaging can be abstracted to "here's the source, the name and the version - go!" and that's the abstraction many distros provide.
- hnfong 2y ago
  Yes, and everyone knows what those options are, and can expect the same flow for each package because... ... autoconf is popular.
  - wakawaka28 2y ago
    You're partly right but autoconf's design is pretty rigid. I've never seen one where the install destination isn't set via one of the standard flags like --prefix. But I have seen other build systems randomize their install processes. Maybe this is a function of what kind of people use each tool. Autotools is mainly adopted by experienced geeks. Other build systems are more beginner-friendly and that might result in less appropriate solutions being written.
    - jujube3 2y ago
      Once you leave behind the simple things like --prefix, it's not that standardized. But, arguing over this is futile, this wheel has been reinvented innumerable times.

zxspectrum1982 2y ago

My main problem with autotools has never been m4 but the fact that they don't provide a good experience on Windows. Cygwin is not something you want to depend on due to performance, and while MSYS has made great strides, as of 2024 it's not yet perfect. IMHO people invented CMake and other build systems after being tired of trying to get autotools to provide a nice experience on Windows.