1. 29

  2. 20

    Autotools solves problems I do not have. I’m sure there are people out there who do have them but I don’t know how many there are. While I agree that there is something to be said for nearly 30 yrs of hard won knowledge about portability and compilation if that knowledge is slowly growing obsolete with no clear or safe way of identifying the obsolete vs the still necessary then the total value of that knowledge is decreased. It’s like having a book where 30% of it is correct and the rest is not but you don’t know which 30% it is.

    I’m honestly not sure it’s worth the effort to keep maintaining it. There are build systems out there with better underlying architecture and better guarantees for your build. It may be time for Autotools to be put on ice.

    1. 19

      Autotools’ dependency on M4 is actually a huge liability. M4 is clearly not maintained, and it’s starting to show. A release of GNU’s libc more than 2 years ago broke GNU M4, and M4 is still not updated to support the new glibc.

      Here’s Arch Linux’s 2 year old patch, which they still use, to make current GNU M4 compile with current GNU glibc: https://github.com/archlinux/svntogit-packages/blob/packages/m4/trunk/m4-1.4.18-glibc-change-work-around.patch - to my knowledge, all other distros which ship current glibc carry a similar patch.

      The situation is, in my opinion, dire.

      1. 5

        There are still commits to m4 (in the branch-1.4 branch, not master); it’s not unmaintained, although there were no commits from Jan 2017 until July 2020 (when gnulib was updated, which added this particular patch).

        I don’t know why they’re not releasing a new version; I can’t really find any discussion about this. The offered solution is “use a snapshot” 🤷

      2. 13

        I feel like I’m the one person that still gets benefit out of autotools - I deal with AIX shenanigans as part of my day job.

        1. 11

          In my experience, large C projects, which otherwise would be perfect target users of Autotools, avoid Autotools because it lacks support for Visual Studio on Windows and Xcode on macOS. It is distressing this make-or-break feature is not mentioned in this analysis at all.

          1. 2

            I think that’s covered by:

            Unlike several competitors, Automake only works with Make, not with newer build drivers (e.g. Ninja).

            1. 1

              Not quite: that’s talking about build drivers that are only interested in running compilation commands in the right order, and not project generation for IDEs which is what I think /u/sanxiyn is talking about.

          2. 9

            Although the article hints at it, autotools was designed to provide an abstraction across varieties of UNIX in the mid 90s, but that is not the cross platform challenge we face today. A cross platform abstraction is only valuable if it abstracts the things people actually use: Linux, macos, Windows, Android, iOS. Autotools provides an abstraction between Linux and macos, but even there isn’t great since macos wants to do things like Universal Binaries which don’t really conform to the mental model that autotools is providing.

            For the rest, if you need to install an abstraction layer to allow your abstraction layer to work, it might not be a great abstraction layer.

            1. 3

              Well, Autotools do support universal binaries: https://www.gnu.org/software/autoconf/manual/autoconf-2.70/html_node/Multiple-Architectures.html. Also, I think BSDs are things people actually use. But overall you are right.

              1. 10

                Also, I think BSDs are things people actually use

                The differences between Linux with glibc and Linux with musl are similar in scale to the differences between Linux and any of the BSDs these days. By default, autotools builds a load of checks that amount to ‘is the year after around 2005?’ They always pass, because *BSD (including macOS), Linux, Solaris, and so on all support roughly the same amount of POSIX. Then it’s just down to a few differences such as epoll vs kqueue, futex vs umtx and friends, and a handful of other small differences, or things like jails vs cgroups that are such huge abstraction differences that autotools is no help papering over them.

                I have never understood what libtool is supposed to do. In any build system I’ve seen it used for, it contributes a lot of complexity and effectively just forwarded the flags through to gcc / clang.

                1. 7

                  libtool is a lot more useful on systems like AIX, where:

                  • shared libraries in .a archives, static and shared objects exist in the same file (theoretically multiple too)
                  • strip can set flags for shared libraries (including loader flags)
                  • libraries can contain both 32 and 64-bit objects (fat libraries without fat binaries)
                  • there needs to be an export list, which becomes an import list for consumers (fuck writing that yourself, get libtool to do it for you) - did i mention that the import list goes into the library file?
                  • GNU created their own library convention on top of the system one, then added another, then gave you flags to reconcile when creating them
                  1. 3

                    The differences between Linux with glibc and Linux with musl are similar in scale to the differences between Linux and any of the BSDs these days.

                    The differences between glibc and musl are extremely clear when you try to run any binary that was built for glibc, on a musl system. It’s exceedingly difficult to trace these and has taken days out of my life, and usually the problem can be found with a simple check or two. But researching the end-user message that you get is difficult.

                    In some cases, like openmp, it’s easier to rebuild the software without it.

                    1. 2

                      Given the OP is about Autotools, this probably was about compiling from source for those targets, not running existing binaries against other libraries.

                      1. 1

                        And the point is that those architectures are different enough that compiling for GNU Libc does not mean compilation for Musl Libc.

                        Anything OpenMP does not work. You need to install ftw (file tree walk) headers to get some things to run. Other things have GNU-specific parts and you have to hand edit them or compile without features because otherwise it can’t get it to build. My point was that it’s easy to brush off the differences when you do not have to face them, and the main reason you don’t have to face them with 99% of software is because autotools is taking care of it for you.

                        Have you ever tried to compile something using cmake for 32 bit, while on a 64 bit machine, without installing 32 bit versions of everything and a separate toolchain? I had to build openjk from source because the developers did not do 64bit builds of Movie Battles II, for Linux. It’s easy enough to brush that off as a problem with the developer, but quite franky that does not matter, all I cared about was playing the game to relieve stress, not adding more stress to my life. I ended up digging out a buggy version of openjk which was from 4 years ago just to get it to work. Which worked “well enough”, but there are frustrating, occasional game breaking bugs that have been fixed in newer versions of openjk, that I can’t fix without a lot of trouble on my end because there was no way to do it with cmake, it does not provide the option.

                        Autotools would have done it with no (or barely any) problems.

              2. 3

                Just try compiling a program on a Raspberry Pi that uses Autohell. The feature-checks take much more time than the compilation itself, while they are completely unnecessary. It’s true that it’s often the author’s fault, because it’s such a mess most people just end up copying one and the same 10k-LOC autohell-macro. Even worse if you suddenly have multiple autohell-runs. Even worse, autohell often gets in my way when it’s feature-test-macros have regressions (that happen quite often when I upgrade gcc or something else) that are thrown as errors, preventing me from continuing compiling even though I know it’s just autohell’s stupidity at play.

                I don’t want to know how much time and energy has been and is being wasted on this superfluous mess, but it could’ve been spent on much more pressing issues in the free software ecosystem.

                For portability, we at suckless usually have a config.mk that is included in the Makefile, and it contains all the portability-related aspects (library locations, man-paths, etc.) and I have yet to see a distribution where “porting” a suckless program involves more than, if it not works out of the box, changing a few of those lines; the Makefile always remains untouched. Admittedly, there are more complex programs around, but even there you can most likely work it out with a good Makefile-system (possibly using a configuration-include) and an impossibility probably means a fault in the program’s design.

                For what it’s worth, I can’t wait for the autohell to disappear. It had it’s purpose in the 90’s and early 2000’s, but now it’s just a waste of time and space and other much simpler and more streamlined build systems easily replace it.

                1. 1

                  I wrote my own configure script for Oil… I think there were a few bugs reported in the beginning, but it seems to work fine now.


                  Granted a shell is pretty easy since it has almost no dependencies. But I think it is not a bad idea and you only have to know shell. I don’t know m4, and I only know some Make and Perl.

                  The fact that autotools uses those 4 languages is definitely kinda crazy.