5 ms·

The article downplays a little bit the value of the autotools. It's not just about building for 30-year ago hosts, it's also about providing a lot of convenient

by vbernat 10y ago

The article downplays a little bit the value of the autotools. It's not just about building for 30-year ago hosts, it's also about providing a lot of convenient tools and providing the user with a known interface. If you write your own configure, people may expect to be able to pass additional CFLAGS (not overriding the existing one), setting the path to various elements, installing in a different root, having certain targets for the generated makefiles (like dist, clean, install, uninstall), having cross-compilation work (including crosscompiling to Windows with mingw64 which solves the toolchain problem of releasing binaries for Windows), ... It's a tedious task and easy to get wrong. On the other hand, using the autotools in a modern way is dead easy. You don't need to add many many tests if you don't intend to support old stuff. You get access to automake which is a fantastic tool on its own. Don't read old tutorials, don't look at how big established projects are doing, look at the Autotools Mythbuster instead (autotools.io) and start with a minimal configure.ac.

Sir_Cmpwn 10y ago
If you use a simpler configure solution, then the user probably won't have much trouble figuring out how to deal with niche edge cases that they expect to work with autotools. On the other hand, when something goes wrong with autotools, the first step is to pour yourself a drink.
pksadiq 10y ago
The m4 macros (autoreconf) and ./configure is too slow when it can be not. Of course './configure -C' may speed up running it a bit. Still not fast enough. I really feel a need for something like AC_TRUST_HOST or AC_TRUST_DISTRO or something like that would not check for each header or each function in some library. Instead it will check the version of GCC, libc, and compile some (hopefully just one) program and test. Of course the common tests shall be skipped only in popular distributions. Say, Debian, Arch, Fedora (and their derivatives), to name a few.
zbuf 10y ago
> If you write your own configure, people may expect to be able to [...] It's a tedious task and easy to get wrong. The author's point is to do <em>without</em> a configure step entirely, not write your own. A standard Makefile is perfectly capable of implementing these things in a manner which is clean, reasonably portable and without the level of indirection that makes things hard to debug. My own experience is that autotools has evolved to feel less standard than the modern platforms it purports to smooth over the differences in; I seem to frequently find that I can't generate a 'configure' for a 3rd party software or libraries from Git repositories because I of the wrong autotools versions. Efforts to investigate this by unpicking the various macros etc. provided in the build have almost always been unsuccessful, leaving me building from distributed .tar.gz files. With something that feels like such a moving target after 30 years, I'm glad to see people realising the benefit of a simple Makefile that's easy to customise for the edge cases.
- vbernat 10y ago
  He also says later in the post you can write your own configure with a bit of bourne shell. If you expect your software to be widely distributed, a custom build script is a pain for distributions as most of them are heavily relying on ./configure && make with the appropriate arguments. Distributions also rely on the ability to override certain flags, something easy to do with autotools and quite hard with plain Makefiles (compare ./configure CFLAGS=... and make CFLAGS=..., the former don't override upstream CFLAGS). I don't object that many projects have convulated and dated autotools scripts notably because they don't age well. It's easy to accumulate a lot of crap. Most projects don't get autotools because they don't know how to use plain Makefile. They do because autotools bring much more than that.
- tannhaeuser 10y ago
  I wish standard (POSIX) Make would be sufficient but it frequently isn't. While some Make features from GNU and BSD Make made it into the POSIX spec (such as "include"), I frequently find myself desiring a more orthogonal facility to integrate output of external programs into Make builds. That is, by using POSIX Make's "VAR=`cmd`" syntax with backtick-quoted commands (or other shell evaluation syntax), you can define macros programmatically for incorporation into build rules as lazily evaluated text substitution variables, but you can use those only in build rules rather than in requisites or targets (where they get interpreted verbatim). A partial solution would be adopting GNU Make's eager evaluation syntax (VAR:=`...`) into POSIX. OTOH, while I'm not a big fan of autotools internals (especially libtool), being able to run "./configure && make install" on tens of thousands of F/OSS packages is something I'd hate to loose. In fact, the extreme consistency in installation procedures (including use of pkg_conf etc.) and discipline in directory layout accross so many F/OSS packages is something I very much admire, given it's an unexpected outcome of a "Bazaar" style development model.
  - dTal 10y ago
    >"./configure && make install" You forgot 'make'! I'm tempted to turn this into a cheap shot about how the consistency obviously isn't worth much, but I won't.
deleted 10y ago
[deleted]
coldtea 10y ago
>The article downplays a little bit the value of the autotools. It's not just about building for 30-year ago hosts, it's also about providing a lot of convenient tools and providing the user with a known interface. If you write your own configure, people may expect to be able to pass additional CFLAGS (not overriding the existing one), setting the path to various elements, installing in a different root, having certain targets for the generated makefiles (like dist, clean, install, uninstall), having cross-compilation work (including crosscompiling to Windows with mingw64 which solves the toolchain problem of releasing binaries for Windows), ... It's a tedious task and easy to get wrong. So why not get a tool with 1/10 the complexity and 1/100 the legacy stuff of Autotool, but the same interface otherwise? People who need the old checks 100% could continue to use Autotool-old, people who don't care for such BS could use the new.
- simias 10y ago
  I don't understand what you mean, if it has the same interface as autotools how do you remove the legacy stuff without breaking anything? Autotools is a huge pain in the ass for the dev, unfortunately I haven't found any alternative that didn't end up being an even bigger annoyance. A decent, simple, easily customizable and portable C/C++ build system is still very much a unsolved problem as far as I'm concerned (and I've tried quite a few of them). At least autotools are supported basically everywhere.
  - heinrich5991 10y ago
    Have you tried cmake?
    - sqeaky 10y ago
      This whole discussion and article had me thinking about that. CMake is faster than autotools and works fine with all the compilers talked about so far and all the windows compilers I know of. Creating a CMakeLists.txt covering moderately complex build that links against a few libraries (but doesn't need and custom logic for moving files or other uncommon stuff) is normally just a few lines of code. Usually just one line of code per source file and per library (depending on how you feel about automatically including files this can be further shortened), then a little bit declaring the language and other settings. There are plenty of 10 line CMakeLists that can build large and seemingly complex projects.
maxlybbert 10y ago
It is true that Autotools offer some nice standard options to use when building and installing software. However, for whatever reason, the ability to figure out portability differences seems to be the selling point to many programmers ( http://queue.acm.org/detail.cfm?id=2349257 http://queue.acm.org/detail.cfm?id=2349257 , https://varnish-cache.org/docs/4.0/phk/autocrap.html https://varnish-cache.org/docs/4.0/phk/autocrap.html ).

by vbernat 10y ago

Sir_Cmpwn 10y ago

If you use a simpler configure solution, then the user probably won't have much trouble figuring out how to deal with niche edge cases that they expect to work with autotools. On the other hand, when something goes wrong with autotools, the first step is to pour yourself a drink.

pksadiq 10y ago

The m4 macros (autoreconf) and ./configure is too slow when it can be not. Of course './configure -C' may speed up running it a bit. Still not fast enough. I really feel a need for something like AC_TRUST_HOST or AC_TRUST_DISTRO or something like that would not check for each header or each function in some library. Instead it will check the version of GCC, libc, and compile some (hopefully just one) program and test. Of course the common tests shall be skipped only in popular distributions. Say, Debian, Arch, Fedora (and their derivatives), to name a few.

zbuf 10y ago

> If you write your own configure, people may expect to be able to [...] It's a tedious task and easy to get wrong. The author's point is to do <em>without</em> a configure step entirely, not write your own. A standard Makefile is perfectly capable of implementing these things in a manner which is clean, reasonably portable and without the level of indirection that makes things hard to debug. My own experience is that autotools has evolved to feel less standard than the modern platforms it purports to smooth over the differences in; I seem to frequently find that I can't generate a 'configure' for a 3rd party software or libraries from Git repositories because I of the wrong autotools versions. Efforts to investigate this by unpicking the various macros etc. provided in the build have almost always been unsuccessful, leaving me building from distributed .tar.gz files. With something that feels like such a moving target after 30 years, I'm glad to see people realising the benefit of a simple Makefile that's easy to customise for the edge cases.

vbernat 10y ago
He also says later in the post you can write your own configure with a bit of bourne shell. If you expect your software to be widely distributed, a custom build script is a pain for distributions as most of them are heavily relying on ./configure && make with the appropriate arguments. Distributions also rely on the ability to override certain flags, something easy to do with autotools and quite hard with plain Makefiles (compare ./configure CFLAGS=... and make CFLAGS=..., the former don't override upstream CFLAGS). I don't object that many projects have convulated and dated autotools scripts notably because they don't age well. It's easy to accumulate a lot of crap. Most projects don't get autotools because they don't know how to use plain Makefile. They do because autotools bring much more than that.
tannhaeuser 10y ago
I wish standard (POSIX) Make would be sufficient but it frequently isn't. While some Make features from GNU and BSD Make made it into the POSIX spec (such as "include"), I frequently find myself desiring a more orthogonal facility to integrate output of external programs into Make builds. That is, by using POSIX Make's "VAR=`cmd`" syntax with backtick-quoted commands (or other shell evaluation syntax), you can define macros programmatically for incorporation into build rules as lazily evaluated text substitution variables, but you can use those only in build rules rather than in requisites or targets (where they get interpreted verbatim). A partial solution would be adopting GNU Make's eager evaluation syntax (VAR:=`...`) into POSIX. OTOH, while I'm not a big fan of autotools internals (especially libtool), being able to run "./configure && make install" on tens of thousands of F/OSS packages is something I'd hate to loose. In fact, the extreme consistency in installation procedures (including use of pkg_conf etc.) and discipline in directory layout accross so many F/OSS packages is something I very much admire, given it's an unexpected outcome of a "Bazaar" style development model.
- dTal 10y ago
  >"./configure && make install" You forgot 'make'! I'm tempted to turn this into a cheap shot about how the consistency obviously isn't worth much, but I won't.

deleted 10y ago

[deleted]

coldtea 10y ago

>The article downplays a little bit the value of the autotools. It's not just about building for 30-year ago hosts, it's also about providing a lot of convenient tools and providing the user with a known interface. If you write your own configure, people may expect to be able to pass additional CFLAGS (not overriding the existing one), setting the path to various elements, installing in a different root, having certain targets for the generated makefiles (like dist, clean, install, uninstall), having cross-compilation work (including crosscompiling to Windows with mingw64 which solves the toolchain problem of releasing binaries for Windows), ... It's a tedious task and easy to get wrong. So why not get a tool with 1/10 the complexity and 1/100 the legacy stuff of Autotool, but the same interface otherwise? People who need the old checks 100% could continue to use Autotool-old, people who don't care for such BS could use the new.

simias 10y ago
I don't understand what you mean, if it has the same interface as autotools how do you remove the legacy stuff without breaking anything? Autotools is a huge pain in the ass for the dev, unfortunately I haven't found any alternative that didn't end up being an even bigger annoyance. A decent, simple, easily customizable and portable C/C++ build system is still very much a unsolved problem as far as I'm concerned (and I've tried quite a few of them). At least autotools are supported basically everywhere.
- heinrich5991 10y ago
  Have you tried cmake?
  - sqeaky 10y ago
    This whole discussion and article had me thinking about that. CMake is faster than autotools and works fine with all the compilers talked about so far and all the windows compilers I know of. Creating a CMakeLists.txt covering moderately complex build that links against a few libraries (but doesn't need and custom logic for moving files or other uncommon stuff) is normally just a few lines of code. Usually just one line of code per source file and per library (depending on how you feel about automatically including files this can be further shortened), then a little bit declaring the language and other settings. There are plenty of 10 line CMakeLists that can build large and seemingly complex projects.

maxlybbert 10y ago

It is true that Autotools offer some nice standard options to use when building and installing software. However, for whatever reason, the ability to figure out portability differences seems to be the selling point to many programmers ( http://queue.acm.org/detail.cfm?id=2349257 http://queue.acm.org/detail.cfm?id=2349257 , https://varnish-cache.org/docs/4.0/phk/autocrap.html https://varnish-cache.org/docs/4.0/phk/autocrap.html ).