4 ms·

The Autotools are better than every other supposedly better solution. I do a lot of distro packaging work, and I can say, without a doubt, that the most proble

The Autotools are better than every other supposedly better solution. I do a lot of distro packaging work, and I can say, without a doubt, that the most problematic software to package are the ones that don't use the autotools.

mikepurvis 11y ago
I don't know Autotools, but I find the CMake workflow to be tolerable. Can someone who knows both provide a comparison?
- jordigh 11y ago
  The golden idea in autotools is test for features not for versions. Allow me to explain. The problem autotools tries to solve is building your software on a wide array of operating systems and configurations. A very attractive alternative approach taken by most, including CMake[1], is to have a big giant database of systems and what each system can do at which version. Thus, if you want to use a library such as, say, Qt, CMake has a Qt module that looks for Qt libraries, checks their versions, and reports that back to you. These databases of system versions and what is available at each version are necessarily always outdated. Autotools instead gives you tools to write tests. Do you need this library? Which functions do you need from this library? What should those functions do? When you're running a ./configure script, that's what autotools is doing. It's checking to see what kind of C library you have, what kind of Unix tools are available, how do those Unix tools behave. It is not going to trust version strings or software names. Perhaps the OS reports that it's Debian but in fact it's some derivative of Debian that changed some things around. If you were relying on CMake's hypothetical database of Debian features, it would fail on this not-quite-Debian system. Over time, these tests get shared around and become part of the core autotools libraries, which is the other problem: autotools is now checking for the absence of certain features that have not really been missing in any system since 1995. --- [1] CMake can perform autoconf-like feature checks too, but this is not as common as relying on its databases of systems and features.
  - davexunit 11y ago
    That was a nice explanation of what is both good and bad about Autotools. I would love to see the GNU project take that "golden idea" and use a better language (GNU Guile ;) because M4 just sucks.
  - manawy 11y ago
    I'm not sure what you mean by databases of systems and features... I use CMake everyday and for me it's not a database but a set of modules. Each of this module will look for a particular thing. Some modules are better written than other but they all allow you to bypass them. Of course on obscure systems it will fail. That's why they are called obscure. But on systems following more or less the good practice, there will be no problem at all. On the others, you need to pass the specific path, but it will be true with autoconf too... no magic here... Also in the doc, it is stated that if you rely on a specific flag/option/function then you need to test for it, and CMake gives you the tool to do it. That's a good practice everyone should follow. But I agree, it's not always done. Like Autoconf, I guess it really depends on how well the developer understand the tool, and how much time he is ready to spend on it. There's no magic, it's a complicated problem, with only complicated solutions. CMake is more attractive to me, because it allows me to do simple stuff easily, but more complicated operations are also possible.
    - jordigh 11y ago
      > I'm not sure what you mean by databases of systems and features... I didn't really mean a literal database. I meant stuff like this: https://github.com/Kitware/CMake/blob/master/Modules/FindQt4.cmake#L1068 https://github.com/Kitware/CMake/blob/master/Modules/FindQt4... This is pretty typical CMake. It's encoding that for a particular version of Qt, add a few more compilation flags. It's a "knowledge base" of Qt versions encoded as a CMake module. The autoconf way would be to try to link a minimal program to Qt, and if it fails, try to see if adding more libraries makes the linking succeed. Or this, for example: https://github.com/Kitware/CMake/blob/master/Modules/FindOpenSSL.cmake#L112 https://github.com/Kitware/CMake/blob/master/Modules/FindOpe... It is trying to account for two popular compilers on Windows but not with Cygwin. It's the whole chain of "if Windows, if cygwin, if mingw, if msvc" what I called a "database" above. Doesn't clang work on Windows these days? What will this knowledge base do now? Shouldn't clang work almost like mingw? But because it misses the "if mingw" branch, code that probably would have worked for clang will be skipped over.
pcwalton 11y ago
> The Autotools are better than every other supposedly better solution. ... as long as you don't care about Windows (or iOS, or Android, etc.)
- rockdoe 11y ago
  Autotools works for Windows and Android NDK builds. No idea about iOS.
buserror 11y ago
While I also spend my day compiling packages [0] -- well CROSS COMPILING packages, and the worst problem I have, bar none, is autocrap. Not only is it a giant pile of poo to try to 'repair' when it invariably does something the wrong way (like trying to fish my host's headers), but when compiling a distro, it's also the single tool that takes the most io/cpu of the host; forget compiling C++ - when you add up the zillion's time autocrap tries to see if I have strtok() in my C headers (hint, I do, since 1991); and then doing it again, over and over and over and over, the /compile/ time becomes rather negligible in comparison to the /autocrap/ time (especially on a modern host with -j12). The thing is, in MOST CASES you could do it all with a page of gmake. pkg-config and all that are excellent at removing the need for autocrap. gmake has made heaps and bounds at simplifying what used to be the nightmarish Makefiles. [0]: I'm the author of https://github.com/buserror/minifs https://github.com/buserror/minifs

mikepurvis 11y ago

I don't know Autotools, but I find the CMake workflow to be tolerable. Can someone who knows both provide a comparison?

jordigh 11y ago
The golden idea in autotools is test for features not for versions. Allow me to explain. The problem autotools tries to solve is building your software on a wide array of operating systems and configurations. A very attractive alternative approach taken by most, including CMake[1], is to have a big giant database of systems and what each system can do at which version. Thus, if you want to use a library such as, say, Qt, CMake has a Qt module that looks for Qt libraries, checks their versions, and reports that back to you. These databases of system versions and what is available at each version are necessarily always outdated. Autotools instead gives you tools to write tests. Do you need this library? Which functions do you need from this library? What should those functions do? When you're running a ./configure script, that's what autotools is doing. It's checking to see what kind of C library you have, what kind of Unix tools are available, how do those Unix tools behave. It is not going to trust version strings or software names. Perhaps the OS reports that it's Debian but in fact it's some derivative of Debian that changed some things around. If you were relying on CMake's hypothetical database of Debian features, it would fail on this not-quite-Debian system. Over time, these tests get shared around and become part of the core autotools libraries, which is the other problem: autotools is now checking for the absence of certain features that have not really been missing in any system since 1995. --- [1] CMake can perform autoconf-like feature checks too, but this is not as common as relying on its databases of systems and features.
- davexunit 11y ago
  That was a nice explanation of what is both good and bad about Autotools. I would love to see the GNU project take that "golden idea" and use a better language (GNU Guile ;) because M4 just sucks.
- manawy 11y ago
  I'm not sure what you mean by databases of systems and features... I use CMake everyday and for me it's not a database but a set of modules. Each of this module will look for a particular thing. Some modules are better written than other but they all allow you to bypass them. Of course on obscure systems it will fail. That's why they are called obscure. But on systems following more or less the good practice, there will be no problem at all. On the others, you need to pass the specific path, but it will be true with autoconf too... no magic here... Also in the doc, it is stated that if you rely on a specific flag/option/function then you need to test for it, and CMake gives you the tool to do it. That's a good practice everyone should follow. But I agree, it's not always done. Like Autoconf, I guess it really depends on how well the developer understand the tool, and how much time he is ready to spend on it. There's no magic, it's a complicated problem, with only complicated solutions. CMake is more attractive to me, because it allows me to do simple stuff easily, but more complicated operations are also possible.
  - jordigh 11y ago
    > I'm not sure what you mean by databases of systems and features... I didn't really mean a literal database. I meant stuff like this: https://github.com/Kitware/CMake/blob/master/Modules/FindQt4.cmake#L1068 https://github.com/Kitware/CMake/blob/master/Modules/FindQt4... This is pretty typical CMake. It's encoding that for a particular version of Qt, add a few more compilation flags. It's a "knowledge base" of Qt versions encoded as a CMake module. The autoconf way would be to try to link a minimal program to Qt, and if it fails, try to see if adding more libraries makes the linking succeed. Or this, for example: https://github.com/Kitware/CMake/blob/master/Modules/FindOpenSSL.cmake#L112 https://github.com/Kitware/CMake/blob/master/Modules/FindOpe... It is trying to account for two popular compilers on Windows but not with Cygwin. It's the whole chain of "if Windows, if cygwin, if mingw, if msvc" what I called a "database" above. Doesn't clang work on Windows these days? What will this knowledge base do now? Shouldn't clang work almost like mingw? But because it misses the "if mingw" branch, code that probably would have worked for clang will be skipped over.

pcwalton 11y ago

> The Autotools are better than every other supposedly better solution. ... as long as you don't care about Windows (or iOS, or Android, etc.)

rockdoe 11y ago
Autotools works for Windows and Android NDK builds. No idea about iOS.

buserror 11y ago

While I also spend my day compiling packages [0] -- well CROSS COMPILING packages, and the worst problem I have, bar none, is autocrap. Not only is it a giant pile of poo to try to 'repair' when it invariably does something the wrong way (like trying to fish my host's headers), but when compiling a distro, it's also the single tool that takes the most io/cpu of the host; forget compiling C++ - when you add up the zillion's time autocrap tries to see if I have strtok() in my C headers (hint, I do, since 1991); and then doing it again, over and over and over and over, the /compile/ time becomes rather negligible in comparison to the /autocrap/ time (especially on a modern host with -j12). The thing is, in MOST CASES you could do it all with a page of gmake. pkg-config and all that are excellent at removing the need for autocrap. gmake has made heaps and bounds at simplifying what used to be the nightmarish Makefiles. [0]: I'm the author of https://github.com/buserror/minifs https://github.com/buserror/minifs