5 ms·

First thing that comes to my mind is the best-in-class cross-UNIX compatibility. But shouldn't the question be the other way around: What can the modern tools d

First thing that comes to my mind is the best-in-class cross-UNIX compatibility. But shouldn't the question be the other way around: What can the modern tools do that autotools can't?

dragontamer 6y ago
The obvious: CMake compiles into either Makefiles or Visual Studio solutions, allowing for cross Linux / Windows builds. Support for Ninja files also seems to speed up builds in my experience. (Ninja is a Makefile "assembly language", minimal features, assuming that things like CMake files compile into Ninja). Ninja is fully multithreaded and focused on speed instead of features, and it really does show. Since ./configure is single-threaded, a substantial amount of time needs to be spent whenever you make changes to your Autoconf / Automake stuff. CMake has a few nice things: a built in basic testing framework (just interpreting the exit codes of programs: 0 is success and anything else is test-failure). Said testing framework has been integrated into various other test frameworks (like Googletest: https://cmake.org/cmake/help/latest/module/GoogleTest.html https://cmake.org/cmake/help/latest/module/GoogleTest.html).
- galangalalgol 6y ago
  And good integration with conan. Dependency management is nice. Vcpkg is getting there too.
  - jnxx 6y ago
    The problem with conan is that it is yet another language-specific package manager. This is especially fatal since the importance of pure C and C++ projects is shrinking in proportion, and both are more and more used in cross-language projects. And for the latter, I think a Linux distribution or a system like GNU Guix is much better suited.
    - galangalalgol 6y ago
      Distro managers lag and are fragmented. Guix looks good. Neither support windows though If you have that need. Trying to use conan in a blended c++/rust code base hasn't been that bad, but that is because we weren't using any crate outside stdlib.
- nrclark 6y ago
  Autotools actually has some built-in test framework support too. A Makefile.am can have one or more programs marked as TEST, which will run when `make check` is executed. Depending on how you set it up, Automake knows how to use the TAP protocol to collect the pass/fail from your tests. You can also run `make distcheck` to generate a source tarball, extract/build the tarball in isolation, and run `make check` on the result. A very handy way to make sure that you've packaged everything correctly, and everything builds/tests OK when executed out-of-tree.
  - nrclark 6y ago
    To those who downvoted my parent comment, what was your reasoning? Not trying to troll - I was just trying to explain a useful Autotools feature in a discussion about Autotools and CMake features.
- jnxx 6y ago
  > The obvious: CMake compiles into either Makefiles or Visual Studio solutions, allowing for cross Linux / Windows builds. I get that this is especially attractive for some companies earning money with Windows. But how important are contributions from developers on Windows for Linux distributions and the free software community? I think that most companies which use open source libraries on Windows are unlikely to give anything back. Also, when it comes to things like networking and server software, Windows has many important differences, and is not that relevant at all any more. Well, every project will need to figure out on its own whether supporting Windows builds is worth the time and hassle.
chiumichael 6y ago
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.

First thing that comes to my mind is the best-in-class cross-UNIX compatibility. But shouldn't the question be the other way around: What can the modern tools do that autotools can't?

dragontamer 6y ago

The obvious: CMake compiles into either Makefiles or Visual Studio solutions, allowing for cross Linux / Windows builds. Support for Ninja files also seems to speed up builds in my experience. (Ninja is a Makefile "assembly language", minimal features, assuming that things like CMake files compile into Ninja). Ninja is fully multithreaded and focused on speed instead of features, and it really does show. Since ./configure is single-threaded, a substantial amount of time needs to be spent whenever you make changes to your Autoconf / Automake stuff. CMake has a few nice things: a built in basic testing framework (just interpreting the exit codes of programs: 0 is success and anything else is test-failure). Said testing framework has been integrated into various other test frameworks (like Googletest: https://cmake.org/cmake/help/latest/module/GoogleTest.html https://cmake.org/cmake/help/latest/module/GoogleTest.html).

galangalalgol 6y ago
And good integration with conan. Dependency management is nice. Vcpkg is getting there too.
- jnxx 6y ago
  The problem with conan is that it is yet another language-specific package manager. This is especially fatal since the importance of pure C and C++ projects is shrinking in proportion, and both are more and more used in cross-language projects. And for the latter, I think a Linux distribution or a system like GNU Guix is much better suited.
  - galangalalgol 6y ago
    Distro managers lag and are fragmented. Guix looks good. Neither support windows though If you have that need. Trying to use conan in a blended c++/rust code base hasn't been that bad, but that is because we weren't using any crate outside stdlib.
nrclark 6y ago
Autotools actually has some built-in test framework support too. A Makefile.am can have one or more programs marked as TEST, which will run when `make check` is executed. Depending on how you set it up, Automake knows how to use the TAP protocol to collect the pass/fail from your tests. You can also run `make distcheck` to generate a source tarball, extract/build the tarball in isolation, and run `make check` on the result. A very handy way to make sure that you've packaged everything correctly, and everything builds/tests OK when executed out-of-tree.
- nrclark 6y ago
  To those who downvoted my parent comment, what was your reasoning? Not trying to troll - I was just trying to explain a useful Autotools feature in a discussion about Autotools and CMake features.
jnxx 6y ago
> The obvious: CMake compiles into either Makefiles or Visual Studio solutions, allowing for cross Linux / Windows builds. I get that this is especially attractive for some companies earning money with Windows. But how important are contributions from developers on Windows for Linux distributions and the free software community? I think that most companies which use open source libraries on Windows are unlikely to give anything back. Also, when it comes to things like networking and server software, Windows has many important differences, and is not that relevant at all any more. Well, every project will need to figure out on its own whether supporting Windows builds is worth the time and hassle.

chiumichael 6y ago

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.