5 ms·

This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rat

This documentation and video is good if you want to use autotools. But in 2016, you should really be asking yourself if autotools is the right choice. It is rather baroque, and there are many other choices these days that provide similar functionality for less developer time and effort.

highwind 11y ago
Could you provide some examples of other choices that you speak of? Thank you.
- rhodysurf 11y ago
  Cmake and Scons
- misframer 11y ago
  Perhaps CMake?
- pedrow 11y ago
  Premake (https://premake.github.io/ https://premake.github.io/)
- thallian 11y ago
  waf (https://waf.io/ https://waf.io/)
  - JoshTriplett 11y ago
    Please don't use waf. It does not provide a stable API from version to version, and encourages projects to embed a binary compiled version of waf. Unlike autotools, where you can ship configure.ac and Makefile.am and expect developers to run autoreconf after obtaining the project from version control, you can't easily do the same thing with waf due to the lack of versioning.
    - ziotom78 11y ago
      "Binary compiled"? Isn't waf a Python script?
      - JoshTriplett 11y ago
        See the compiled version linked from the waf homepage, which projects using waf include in their source tree. That compiled version consists of a small Python stub followed by bz2-compressed data and a signature.
- antonyme 11y ago
  CMake, Scons, Ninja, Gyp There are many more, but these are more viable alternatives to auto tools. https://en.wikipedia.org/wiki/List_of_build_automation_software https://en.wikipedia.org/wiki/List_of_build_automation_softw...
cperciva 11y ago
To elaborate on "baroque": autotools spends a lot of time and effort on detecting behaviours which (a) no new Unix system has exhibited for at least two decades, and (b) your code almost certainly isn't going to be able to handle anyway. Autotools was great once, but the world has moved on. Write code which is POSIX compliant and skip the whole mess.
- dmm 11y ago
  As a user building packages I like autotools because of its uniformity. If I want to change the install root I use "--prefix". If I want to crosscompile I can set "--build" and "--host". If I need to set a compiler flag, autotools actually observes CFLAGS. A few years ago I was trying to install a python extension and I couldn't figure out how to set a cflag on the native code it was compiling. It ignored CC, CFLAGS, etc. The documentation said nothing about it, super frustrating.
  - illumen 11y ago
    Weird. CC and CFLAGS should both work with standard distutils.
    - dmm 11y ago
      That's the frustrating thing, other python libraries worked fine. That one must have been doing something weird.
  - scrollaway 11y ago
    CMake is a million times better than autotools and respects prefix-setting, cross compiling etc in standard ways as well. Uniformity is not unique to autotools. CPython extension building, however, sucks. setup.py is a bit of an abomination... It's really every language decides to reinvent the wheel for their own language. By now we could've had standards, and standard software, for package distribution and installation instead of having pip, go get, npm and a thousand others.
    - 11y ago
_ZeD_ 11y ago
what are the alternatives?
davexunit 11y ago
All of the supposed replacements usually have a better interface but way worse functionality. Even just simple things like setting the installation prefix and finding shared libraries don't work as well or are left out. I do a lot of distro packaging work, and the GNU build system is by far the easiest to deal with. What the Autotools could benefit greatly from is a new UI. We can all agree that M4 sucks big time.
- shadowmint 11y ago
  worse functionality how? Im honestly curious why anyone still uses these tools. Ive heard the 'alternatives do not work as well' argument before, but no one has ever managed to articulate to me exactly what it is that premake/cmake lack? Is it literally just building debian packages in a moderately convenient manner?

highwind 11y ago

Could you provide some examples of other choices that you speak of? Thank you.

rhodysurf 11y ago
Cmake and Scons
misframer 11y ago
Perhaps CMake?
pedrow 11y ago
Premake (https://premake.github.io/ https://premake.github.io/)
thallian 11y ago
waf (https://waf.io/ https://waf.io/)
- JoshTriplett 11y ago
  Please don't use waf. It does not provide a stable API from version to version, and encourages projects to embed a binary compiled version of waf. Unlike autotools, where you can ship configure.ac and Makefile.am and expect developers to run autoreconf after obtaining the project from version control, you can't easily do the same thing with waf due to the lack of versioning.
  - ziotom78 11y ago
    "Binary compiled"? Isn't waf a Python script?
    - JoshTriplett 11y ago
      See the compiled version linked from the waf homepage, which projects using waf include in their source tree. That compiled version consists of a small Python stub followed by bz2-compressed data and a signature.
antonyme 11y ago
CMake, Scons, Ninja, Gyp There are many more, but these are more viable alternatives to auto tools. https://en.wikipedia.org/wiki/List_of_build_automation_software https://en.wikipedia.org/wiki/List_of_build_automation_softw...

cperciva 11y ago

To elaborate on "baroque": autotools spends a lot of time and effort on detecting behaviours which (a) no new Unix system has exhibited for at least two decades, and (b) your code almost certainly isn't going to be able to handle anyway. Autotools was great once, but the world has moved on. Write code which is POSIX compliant and skip the whole mess.

dmm 11y ago
As a user building packages I like autotools because of its uniformity. If I want to change the install root I use "--prefix". If I want to crosscompile I can set "--build" and "--host". If I need to set a compiler flag, autotools actually observes CFLAGS. A few years ago I was trying to install a python extension and I couldn't figure out how to set a cflag on the native code it was compiling. It ignored CC, CFLAGS, etc. The documentation said nothing about it, super frustrating.
- illumen 11y ago
  Weird. CC and CFLAGS should both work with standard distutils.
  - dmm 11y ago
    That's the frustrating thing, other python libraries worked fine. That one must have been doing something weird.
- scrollaway 11y ago
  CMake is a million times better than autotools and respects prefix-setting, cross compiling etc in standard ways as well. Uniformity is not unique to autotools. CPython extension building, however, sucks. setup.py is a bit of an abomination... It's really every language decides to reinvent the wheel for their own language. By now we could've had standards, and standard software, for package distribution and installation instead of having pip, go get, npm and a thousand others.
  - 11y ago

_ZeD_ 11y ago

what are the alternatives?

davexunit 11y ago

All of the supposed replacements usually have a better interface but way worse functionality. Even just simple things like setting the installation prefix and finding shared libraries don't work as well or are left out. I do a lot of distro packaging work, and the GNU build system is by far the easiest to deal with. What the Autotools could benefit greatly from is a new UI. We can all agree that M4 sucks big time.

shadowmint 11y ago
worse functionality how? Im honestly curious why anyone still uses these tools. Ive heard the 'alternatives do not work as well' argument before, but no one has ever managed to articulate to me exactly what it is that premake/cmake lack? Is it literally just building debian packages in a moderately convenient manner?