7 ms·

Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone complet

by DasIch 11y ago

Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.

wyldfire 11y ago
Well, is that really fair? autotools' scope is great, like you concede. But it was designed around 1991, right? > That everyone else just kind of seemed to go with it There was nothing else better available, and this was effective -- is effective. If you haven't seen the effect of momentum in software, then this is nothing. Look at how x86 systems get bootstrapped; look at how we interact with important platform devices like the RTC (I/O ports). Virtually none of this has changed because it doesn't introduce significant limitations in operating systems or hardware but it's downright odd.
to3m 11y ago
cmake is pretty bad, too, though at least it runs on Windows. (And I don't think it's got quite the same goals as Autotools, though their scopes overlap in many respects.) I've never met anything build-related, scope large or small, that wasn't somewhere between "PHP" (horrid, workable if you're careful, will rot your brain in the long run) and "Cthulhu" (beyond evil, insofar as normal human modes of comprehension can be said to apply). I wonder if this is some kind of, like, Heart of Darkness shit.
Aissen 11y ago
The big problem is that no one did a better solution. All alternatives are missing one or more crucial features of the autotools (most prominent being portability). And that is sad as well.
- rwmj 11y ago
  Cross-compilation is another. When I was building packages for the Fedora MinGW (Windows cross compiler[1]) project, it was mostly trivial to get things working if the package used autotools or cmake, and an impossible nightmare for everything else. [1] https://fedoraproject.org/wiki/Features/Windows_cross_compiler https://fedoraproject.org/wiki/Features/Windows_cross_compil...
nbaksalyar 11y ago
IMO it doesn't matter if there are better alternatives, as that's mostly a concern for new projects. The thing is, there's a good chance that you'll have to use autoconf at least once in your dev life, sooner or later, because very large number of major opensource projects use it (with no clear intent to switch). So at least you've got to be prepared and know how autotools are working.
jordigh 11y ago
but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That is more or less what happened, by their own admission, "why does it look like gorilla spit?" https://www.gnu.org/software/autoconf/manual/autoconf-2.65/autoconf.html#History https://www.gnu.org/software/autoconf/manual/autoconf-2.65/a... Although I disagree that they didn't produce a tolerably decent solution. It's a near hopeless task to account for the differences of dozens of operating systems, even if most of them are all Unix-like, yet autotools still tried and mostly succeeded. Nowadays some build tools don't even attempt to solve this problem and only target Windows, Mac OS X, and Ubuntu, and usually only the latest version of each.
jerf 11y ago
A solution can be no simpler than the essential complexity of the problem it is solving. It is not clear to me that the essential complexity of the problem is significantly simpler than the autotools solution. Across the totality of all C/C++-using systems, across all of the mostly-POSIX and vaguely-POSIX-ish systems, across all the libraries, the toolkits, the OSes, across the decades, across all of what it is trying to span, the essential complexity is quite large. Contemplating all that probably makes autotools come out looking pretty good in context. I'd observe that every major modern language since then has taken an approach that in one way or another, obviates the need for a full autoconf. C's contribution to large-scale code reuse was largely showing all the ways in which it could go wrong, and encouraging future language developers to get it more right to start with, which they mostly have. (Note I'm not saying there aren't any problems with the way any modern language works. But they're still all simpler, generally more powerful, and even in their worst case, nothing like as bad as the autoconf-world's worst case.)
- nickpsecurity 11y ago
  Even as an autotools critic, I totally understand that argument about the steps that were necessary for dealing with those portability problems. Well, way back in the day when they existed to the degree they did. Today, there should be much less complexity as the systems are more alike than different. What complexity is there is mostly a relic from days gone by that never got cleaned up because nobody wants to invest the effort.
  - kazinator 11y ago
    As someone who maintains a hand-written configure script for a project that I build on just a handful of platforms, I have to disagree. There is plenty of cruft there to detect and take care of. For example, recently I discovered that -D_FILE_OFFSET_BITS=64 works on 32 bit Solaris 10 for large file support. However, fseeko and ftello are not declared. For that you need something special, namely -D_LARGEFILE_SOURCE --- this is not just assumed from _FILE_OFFSET_BITS=64. New developments in POSIX have created a fuzzy landscape which resembles some of the confusion in 1990 Unixes. This platform needs _POSIX_C_SOURCE=<at least such>, another has the same thing under _XOPEN_SOURCE. Apple won't declare anything useful to you without -D_DARWIN_SOURCE. Some platform needed __EXTENSIONS__ to declare struct winsize. I don't remember which one, but my script detects that. Systems are not becoming more alike. Even when it comes to standard stuff, they vary in their conformance to POSIX, and in how they declare identifiers and the exact headers that have to be included and such.

by DasIch 11y ago

wyldfire 11y ago

Well, is that really fair? autotools' scope is great, like you concede. But it was designed around 1991, right? > That everyone else just kind of seemed to go with it There was nothing else better available, and this was effective -- is effective. If you haven't seen the effect of momentum in software, then this is nothing. Look at how x86 systems get bootstrapped; look at how we interact with important platform devices like the RTC (I/O ports). Virtually none of this has changed because it doesn't introduce significant limitations in operating systems or hardware but it's downright odd.

to3m 11y ago

cmake is pretty bad, too, though at least it runs on Windows. (And I don't think it's got quite the same goals as Autotools, though their scopes overlap in many respects.) I've never met anything build-related, scope large or small, that wasn't somewhere between "PHP" (horrid, workable if you're careful, will rot your brain in the long run) and "Cthulhu" (beyond evil, insofar as normal human modes of comprehension can be said to apply). I wonder if this is some kind of, like, Heart of Darkness shit.

Aissen 11y ago

The big problem is that no one did a better solution. All alternatives are missing one or more crucial features of the autotools (most prominent being portability). And that is sad as well.

rwmj 11y ago
Cross-compilation is another. When I was building packages for the Fedora MinGW (Windows cross compiler[1]) project, it was mostly trivial to get things working if the package used autotools or cmake, and an impossible nightmare for everything else. [1] https://fedoraproject.org/wiki/Features/Windows_cross_compiler https://fedoraproject.org/wiki/Features/Windows_cross_compil...

nbaksalyar 11y ago

IMO it doesn't matter if there are better alternatives, as that's mostly a concern for new projects. The thing is, there's a good chance that you'll have to use autoconf at least once in your dev life, sooner or later, because very large number of major opensource projects use it (with no clear intent to switch). So at least you've got to be prepared and know how autotools are working.

jordigh 11y ago

but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That is more or less what happened, by their own admission, "why does it look like gorilla spit?" https://www.gnu.org/software/autoconf/manual/autoconf-2.65/autoconf.html#History https://www.gnu.org/software/autoconf/manual/autoconf-2.65/a... Although I disagree that they didn't produce a tolerably decent solution. It's a near hopeless task to account for the differences of dozens of operating systems, even if most of them are all Unix-like, yet autotools still tried and mostly succeeded. Nowadays some build tools don't even attempt to solve this problem and only target Windows, Mac OS X, and Ubuntu, and usually only the latest version of each.

jerf 11y ago

A solution can be no simpler than the essential complexity of the problem it is solving. It is not clear to me that the essential complexity of the problem is significantly simpler than the autotools solution. Across the totality of all C/C++-using systems, across all of the mostly-POSIX and vaguely-POSIX-ish systems, across all the libraries, the toolkits, the OSes, across the decades, across all of what it is trying to span, the essential complexity is quite large. Contemplating all that probably makes autotools come out looking pretty good in context. I'd observe that every major modern language since then has taken an approach that in one way or another, obviates the need for a full autoconf. C's contribution to large-scale code reuse was largely showing all the ways in which it could go wrong, and encouraging future language developers to get it more right to start with, which they mostly have. (Note I'm not saying there aren't any problems with the way any modern language works. But they're still all simpler, generally more powerful, and even in their worst case, nothing like as bad as the autoconf-world's worst case.)

nickpsecurity 11y ago
Even as an autotools critic, I totally understand that argument about the steps that were necessary for dealing with those portability problems. Well, way back in the day when they existed to the degree they did. Today, there should be much less complexity as the systems are more alike than different. What complexity is there is mostly a relic from days gone by that never got cleaned up because nobody wants to invest the effort.
- kazinator 11y ago
  As someone who maintains a hand-written configure script for a project that I build on just a handful of platforms, I have to disagree. There is plenty of cruft there to detect and take care of. For example, recently I discovered that -D_FILE_OFFSET_BITS=64 works on 32 bit Solaris 10 for large file support. However, fseeko and ftello are not declared. For that you need something special, namely -D_LARGEFILE_SOURCE --- this is not just assumed from _FILE_OFFSET_BITS=64. New developments in POSIX have created a fuzzy landscape which resembles some of the confusion in 1990 Unixes. This platform needs _POSIX_C_SOURCE=<at least such>, another has the same thing under _XOPEN_SOURCE. Apple won't declare anything useful to you without -D_DARWIN_SOURCE. Some platform needed __EXTENSIONS__ to declare struct winsize. I don't remember which one, but my script detects that. Systems are not becoming more alike. Even when it comes to standard stuff, they vary in their conformance to POSIX, and in how they declare identifiers and the exact headers that have to be included and such.