4 ms·

Good point. Personally, I've avoided autotools for a long time since many projects use CMake and because of its reputation as a painful thing to learn. Lately,

Good point. Personally, I've avoided autotools for a long time since many projects use CMake and because of its reputation as a painful thing to learn. Lately, however, I've started learning more about autotools, so was just curious as to what it's really good at.

smartmic 6y ago
Oh yes, the reputation of the learning curve precedes it. But the book helped me get started and, as is often the case with complex things, once you've dealt with it a bit, the experience wasn't as bad as I feared.
sramsay 6y ago
I am absolutely the opposite. I've avoided CMake for a long time since many projects use autotools and because of its reputation as a painful thing to learn. ;) But actually, one of the points made in the Calcote book really stuck with me: Build tools are not just about developer convenience; they're also about the user's convenience. It's more work on my end, but my users (who, admittedly, are on UNIX-likes) know to type: ./configure make From their standpoint, it just works as expected.
- taeric 6y ago
  This was a near magical revelation for me. I should finish that book. It is astounding how many tools I have to install to get most tools to work. :(
  - sramsay 6y ago
    It's fascinating, isn't it? Right! Users . . . :)
- fiddlerwoaroof 6y ago
  Yeah, I find it really irritating when a build system doesn’t respect this interface. Really, cargo and all these other tools should have options for generating a configure script and makefile: they could be relatively minimal and just invoke cargo with the appropriate options, but it would make it much easier to build arbitrary projects from source.
- catlifeonmars 6y ago
  I never understood why there are typically two commands and not just “make”. Is this a historical accident?
  - millstone 6y ago
    I think it is simply that make is too crufty to extend. It has perma-broken behavior around space handling, which nobody dares touch [1]. But you can't replace it because it is entrenched, so Makefiles must be wrapped, by configure or CMake or whatever. And these in turn have their own cruft, so must be wrapped, by autoconf and...well someone please wrap CMake! The C and C++ ecosystem is crying out for a new build system, but there is no mechanism to converge on one. It's bad. 1: http://savannah.gnu.org/bugs/?712 http://savannah.gnu.org/bugs/?712
    - jnxx 6y ago
      Make does what it does surprisingly well: It runs commands on files based on a description of dependencies. There is no shortage of would-be successors of make, but so far none of them has succeeded, which supports the hypothesis that "make" has hit a sweet spot. There is one alternative to make which I think is worth mentioning, because of its simplicity, brilliance, and excellent support for correctness: it is redo, as in Apenwarrs redo: https://redo.readthedocs.io/en/latest/ https://redo.readthedocs.io/en/latest/ And redo works with autotools!
  - jnxx 6y ago
    This is by construction and is nicely explained by the slides I linked before. Basically, autoconf generates a makefile which will work for your architecture. It does that via a script which is called "configure", which generates that makefile. The configure script is independent of your hardware and platform and does only require a standard POSIX shell, and it generates code for the version of "make" that is present on your platform. This means that in difference to other build systems, one does not have to install (and build!) the build system for the own platform, and also that there are no compatibility problems because the configure script always matches the source code distribution. On top of that, the "configure" script is also automatically generated, typically using two files "config.ac" and "makefile.am", via a command which is now called "autoreconf", but this normally happens only on the developer's system.
- jnxx 6y ago
  > From their standpoint, it just works as expected. This is also quite important when you happen to work on larger projects with many dozens or hundreds of modules and you need to build a specific part weeks after you have been looking at them. To have to look up every time how to build something is more than a nuisance.

smartmic 6y ago

Oh yes, the reputation of the learning curve precedes it. But the book helped me get started and, as is often the case with complex things, once you've dealt with it a bit, the experience wasn't as bad as I feared.

sramsay 6y ago

I am absolutely the opposite. I've avoided CMake for a long time since many projects use autotools and because of its reputation as a painful thing to learn. ;) But actually, one of the points made in the Calcote book really stuck with me: Build tools are not just about developer convenience; they're also about the user's convenience. It's more work on my end, but my users (who, admittedly, are on UNIX-likes) know to type: ./configure make From their standpoint, it just works as expected.

taeric 6y ago
This was a near magical revelation for me. I should finish that book. It is astounding how many tools I have to install to get most tools to work. :(
- sramsay 6y ago
  It's fascinating, isn't it? Right! Users . . . :)
fiddlerwoaroof 6y ago
Yeah, I find it really irritating when a build system doesn’t respect this interface. Really, cargo and all these other tools should have options for generating a configure script and makefile: they could be relatively minimal and just invoke cargo with the appropriate options, but it would make it much easier to build arbitrary projects from source.
catlifeonmars 6y ago
I never understood why there are typically two commands and not just “make”. Is this a historical accident?
- millstone 6y ago
  I think it is simply that make is too crufty to extend. It has perma-broken behavior around space handling, which nobody dares touch [1]. But you can't replace it because it is entrenched, so Makefiles must be wrapped, by configure or CMake or whatever. And these in turn have their own cruft, so must be wrapped, by autoconf and...well someone please wrap CMake! The C and C++ ecosystem is crying out for a new build system, but there is no mechanism to converge on one. It's bad. 1: http://savannah.gnu.org/bugs/?712 http://savannah.gnu.org/bugs/?712
  - jnxx 6y ago
    Make does what it does surprisingly well: It runs commands on files based on a description of dependencies. There is no shortage of would-be successors of make, but so far none of them has succeeded, which supports the hypothesis that "make" has hit a sweet spot. There is one alternative to make which I think is worth mentioning, because of its simplicity, brilliance, and excellent support for correctness: it is redo, as in Apenwarrs redo: https://redo.readthedocs.io/en/latest/ https://redo.readthedocs.io/en/latest/ And redo works with autotools!
- jnxx 6y ago
  This is by construction and is nicely explained by the slides I linked before. Basically, autoconf generates a makefile which will work for your architecture. It does that via a script which is called "configure", which generates that makefile. The configure script is independent of your hardware and platform and does only require a standard POSIX shell, and it generates code for the version of "make" that is present on your platform. This means that in difference to other build systems, one does not have to install (and build!) the build system for the own platform, and also that there are no compatibility problems because the configure script always matches the source code distribution. On top of that, the "configure" script is also automatically generated, typically using two files "config.ac" and "makefile.am", via a command which is now called "autoreconf", but this normally happens only on the developer's system.
jnxx 6y ago
> From their standpoint, it just works as expected. This is also quite important when you happen to work on larger projects with many dozens or hundreds of modules and you need to build a specific part weeks after you have been looking at them. To have to look up every time how to build something is more than a nuisance.