3 ms·

I bought this book on autotools a few years ago which demystified it a bunch. https://www.amazon.com/Autotools-Practioners-Autoconf-Automake-Libtool/dp/1593272

I bought this book on autotools a few years ago which demystified it a bunch. https://www.amazon.com/Autotools-Practioners-Autoconf-Automake-Libtool/dp/1593272065 https://www.amazon.com/Autotools-Practioners-Autoconf-Automa... Basically all of the decisions are based on decades of trying to support ever more features, backwards compatibility, many different hackers trying to keep it working for their own projects / companies, etc. It is possible to use autotools nowadays without losing your mind. There is a "safe" path where things just work. I prefer it to CMake, but both are unwieldy beasts.

kazinator 4y ago
> It is possible to use autotools nowadays without losing your mind. Only by punting the problems downstream. "Oh, cross-compiling? Not my problem, ..." GNU programs are the worst. Most of them you can't even build as a developer just by cloning their git repo and doing configure and make. When they ship a GNU program (e.g. GNU BIson or Make or whatever), there is a step that is done to produce the building version and that's what goes into the "official tarball" (now there is an antedeluvial practice right there). To build as a deverloper working on the program, you have to run some "make boostrap" idiocy, which needs the correct version of AutoConf and AutoMake and whatevernot. Of course, every GNU program you boostrap wants different versions of these things, determined by what upstream is using. Oh, git bisect to go backwards a few years? Different tools were used then; re-bootstrap with that ... It's just insanity and AutoTools is at the heart of it.
- monero-xmr 4y ago
  I have found standard distros on relatively recent versions don't have issues with configure / make / make install, or at least issues I can solve fairly easily with googles
  - kazinator 4y ago
    With the release materials you won't see problems on mainstream distros doing configure && make && make install. I'm talking about cloning the program's git repo and working with that. GNU programs don't include the generated configure script in their repos; you have to boostrap that first, and you need all the AutoCruft, in the correct versions which that git baseline of the program wants. It's completely insane. It should be that to create a release of gnu-whatever-1.2.3 you just create a tarball directly out of git using the 1.2.3 version tag. That is the release. But that's not how it works; a release that doesn't require AutoTools has to be specially prepared. Sometimes I have cheated to build a GNU program from sources. I would find the closest matching release tarball and unpack it over the cloned git repo, then run ./configure and all that. Carefully git-reset any differences and so on.
    - monero-xmr 4y ago
      You seem to have a lot of experience with some hairy stuff. Mine consists of creating some open source C projects using autotools, and also cloning / building perhaps 7 projects I frequently use on Ubuntu and popOS which I have not struggled with. But totally believe that autotools hell is widespread. My total nightmare experience has been with CMake, with a project that mixed C and C++. IIRC it had to do with trying to get something to work on LLVM / macOS which it wasn't originally supported for.
      - kazinator 4y ago
        To be clear, I'm dead set against CMake. I would never voluntarily agree with that being introduced anywhere for any purpose. The concept is bad and the implementation is atrocious. In no uncertain terms, CMake is harmful garbage.
        mathstuf 4y ago
        I'm curious: do you mind being a bit more specific? Feel free to send an email (easily discoverable from Git commits I make and end up on Github; same handle here and there). (FD: CMake developer) I certainly understand a lot of the gripes that people have had, but the amount of tribal knowledge for obscure platform behaviors encoded in CMake is…vast. I am certainly in the "things need to improve" camp, but I don't think burning all the bridges that have been built is the way to go either.
    - tomn 4y ago
      While what you said is true, for outsiders it misses the 'why' (which I'm sure you are aware of!). The idea with autotools is that the generated configure script (and other assorted files) is supposed to be forwards and backwards compatible with different systems. It's not perfect, but the behaviour is mostly locked down at the time it is built, based on the particular set of macros it is generated with. There are definitely aspects of this which don't work (it's nearly impossible to test, getting specific versions of autotools is presumably a PITA, and the make-in-bash-in-m4 language is deeply cursed), but the overall design does make some things better. For example, if your project needs a specific version of cmake, your users will have to figure out how to install it, but if your project requires a specific version of autotools, only your developers need to install it. (FWIW autotools is on my 'never again' list of technologies; it's incredibly cursed)
  - rleigh 4y ago
    The reason for the recent stability is that the Autotools have been essentially unmaintained for the past 15 years. When there were steady releases back in the early 2000s, we experienced regular incompatibilities and breakage. Today, there are occasional releases again, but the tools have painted themselves into a corner--it's almost impossible to make any change of note without breaking things.
patrick451 4y ago
Before I started writing software, my main experience with build systems was trying to build a program I wanted that wasn't inside apt. When you're in that position, autotools is much nicer. The paradigm of downloading a release tarball with configure script (which has a --help!), so the end user just needs to do the old ./configure && make && sudo make install is really nice. I found it much easier to tell autotools how to find a library. Autotools made it intuitive to figure out what options were available (configure --help), and I never ran into trouble with my cmake version being too old. But as a developer in c++ land, I much prefer cmake. It integrates very nicely with nearly all other c++ libraries out there. I think modern cmake targets do a nice job of encapsulating how to consume a dependency. And Cmake isn't restricted to only POSIX like platforms. So I suppose it depends on who the target audience is.
JohnFen 4y ago
I very much prefer the autotools to CMake, but I'm 100% sure that's because I'm extremely familiar with them, and not so much with CMake. For personal projects, the tool that that I can use fluently beats other tools every time. But when working in a team, that equation is different.

kazinator 4y ago

> It is possible to use autotools nowadays without losing your mind. Only by punting the problems downstream. "Oh, cross-compiling? Not my problem, ..." GNU programs are the worst. Most of them you can't even build as a developer just by cloning their git repo and doing configure and make. When they ship a GNU program (e.g. GNU BIson or Make or whatever), there is a step that is done to produce the building version and that's what goes into the "official tarball" (now there is an antedeluvial practice right there). To build as a deverloper working on the program, you have to run some "make boostrap" idiocy, which needs the correct version of AutoConf and AutoMake and whatevernot. Of course, every GNU program you boostrap wants different versions of these things, determined by what upstream is using. Oh, git bisect to go backwards a few years? Different tools were used then; re-bootstrap with that ... It's just insanity and AutoTools is at the heart of it.

monero-xmr 4y ago
I have found standard distros on relatively recent versions don't have issues with configure / make / make install, or at least issues I can solve fairly easily with googles
- kazinator 4y ago
  With the release materials you won't see problems on mainstream distros doing configure && make && make install. I'm talking about cloning the program's git repo and working with that. GNU programs don't include the generated configure script in their repos; you have to boostrap that first, and you need all the AutoCruft, in the correct versions which that git baseline of the program wants. It's completely insane. It should be that to create a release of gnu-whatever-1.2.3 you just create a tarball directly out of git using the 1.2.3 version tag. That is the release. But that's not how it works; a release that doesn't require AutoTools has to be specially prepared. Sometimes I have cheated to build a GNU program from sources. I would find the closest matching release tarball and unpack it over the cloned git repo, then run ./configure and all that. Carefully git-reset any differences and so on.
  - monero-xmr 4y ago
    You seem to have a lot of experience with some hairy stuff. Mine consists of creating some open source C projects using autotools, and also cloning / building perhaps 7 projects I frequently use on Ubuntu and popOS which I have not struggled with. But totally believe that autotools hell is widespread. My total nightmare experience has been with CMake, with a project that mixed C and C++. IIRC it had to do with trying to get something to work on LLVM / macOS which it wasn't originally supported for.
    - kazinator 4y ago
      To be clear, I'm dead set against CMake. I would never voluntarily agree with that being introduced anywhere for any purpose. The concept is bad and the implementation is atrocious. In no uncertain terms, CMake is harmful garbage.
      - mathstuf 4y ago
        I'm curious: do you mind being a bit more specific? Feel free to send an email (easily discoverable from Git commits I make and end up on Github; same handle here and there). (FD: CMake developer) I certainly understand a lot of the gripes that people have had, but the amount of tribal knowledge for obscure platform behaviors encoded in CMake is…vast. I am certainly in the "things need to improve" camp, but I don't think burning all the bridges that have been built is the way to go either.
  - tomn 4y ago
    While what you said is true, for outsiders it misses the 'why' (which I'm sure you are aware of!). The idea with autotools is that the generated configure script (and other assorted files) is supposed to be forwards and backwards compatible with different systems. It's not perfect, but the behaviour is mostly locked down at the time it is built, based on the particular set of macros it is generated with. There are definitely aspects of this which don't work (it's nearly impossible to test, getting specific versions of autotools is presumably a PITA, and the make-in-bash-in-m4 language is deeply cursed), but the overall design does make some things better. For example, if your project needs a specific version of cmake, your users will have to figure out how to install it, but if your project requires a specific version of autotools, only your developers need to install it. (FWIW autotools is on my 'never again' list of technologies; it's incredibly cursed)
- rleigh 4y ago
  The reason for the recent stability is that the Autotools have been essentially unmaintained for the past 15 years. When there were steady releases back in the early 2000s, we experienced regular incompatibilities and breakage. Today, there are occasional releases again, but the tools have painted themselves into a corner--it's almost impossible to make any change of note without breaking things.

patrick451 4y ago

Before I started writing software, my main experience with build systems was trying to build a program I wanted that wasn't inside apt. When you're in that position, autotools is much nicer. The paradigm of downloading a release tarball with configure script (which has a --help!), so the end user just needs to do the old ./configure && make && sudo make install is really nice. I found it much easier to tell autotools how to find a library. Autotools made it intuitive to figure out what options were available (configure --help), and I never ran into trouble with my cmake version being too old. But as a developer in c++ land, I much prefer cmake. It integrates very nicely with nearly all other c++ libraries out there. I think modern cmake targets do a nice job of encapsulating how to consume a dependency. And Cmake isn't restricted to only POSIX like platforms. So I suppose it depends on who the target audience is.

JohnFen 4y ago

I very much prefer the autotools to CMake, but I'm 100% sure that's because I'm extremely familiar with them, and not so much with CMake. For personal projects, the tool that that I can use fluently beats other tools every time. But when working in a team, that equation is different.