9 ms·

Autotools Mythbuster

90 points by nbaksalyar 11y ago

raverbashing 11y ago
One of the first lines "...the language used to write the configure.ac is called M4sh, to make clear that it's based off both sh and the macro language M4. " Tip: don't use Autotools
- davexunit 11y ago
  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
- deleted 11y ago
  [deleted]
DasIch 11y ago
Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.
- wyldfire 11y ago
  Well, is that really fair? autotools' scope is great, like you concede. But it was designed around 1991, right? > That everyone else just kind of seemed to go with it There was nothing else better available, and this was effective -- is effective. If you haven't seen the effect of momentum in software, then this is nothing. Look at how x86 systems get bootstrapped; look at how we interact with important platform devices like the RTC (I/O ports). Virtually none of this has changed because it doesn't introduce significant limitations in operating systems or hardware but it's downright odd.
- to3m 11y ago
  cmake is pretty bad, too, though at least it runs on Windows. (And I don't think it's got quite the same goals as Autotools, though their scopes overlap in many respects.) I've never met anything build-related, scope large or small, that wasn't somewhere between "PHP" (horrid, workable if you're careful, will rot your brain in the long run) and "Cthulhu" (beyond evil, insofar as normal human modes of comprehension can be said to apply). I wonder if this is some kind of, like, Heart of Darkness shit.
- Aissen 11y ago
  The big problem is that no one did a better solution. All alternatives are missing one or more crucial features of the autotools (most prominent being portability). And that is sad as well.
  - rwmj 11y ago
    Cross-compilation is another. When I was building packages for the Fedora MinGW (Windows cross compiler[1]) project, it was mostly trivial to get things working if the package used autotools or cmake, and an impossible nightmare for everything else. [1] https://fedoraproject.org/wiki/Features/Windows_cross_compiler https://fedoraproject.org/wiki/Features/Windows_cross_compil...
falcolas 11y ago
While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.
- riffraff 11y ago
  there _is_ a huge amount of smart folks who worked or works on build systems. Sadly, it seems everyone is 80% better than the others in something and 20% lacking in something else. For example, the SCons wiki has some interesting comparisons. https://bitbucket.org/scons/scons/wiki/SconsVsOtherBuildTools https://bitbucket.org/scons/scons/wiki/SconsVsOtherBuildTool...
  - wyldfire 11y ago
    I really liked SCons, but it seems like it never really hit critical mass. Ubiquity is important for a build tool.
- humanrebar 11y ago
  Doesn't CMake count as a successor?
  - rwmj 11y ago
    I think more like "differently bad". However of all the build systems out there (and as a Fedora packager, I have had to deal with many), I'd prefer if you used either autotools or cmake, because those are the ones we're most familiar with and we can fix things.
- rwmj 11y ago
  Of course there are many alternatives (of the alternatives, I can only really recommend cmake). The problems broadly speaking are: * Assumptions: autotools assumes that only a basic Bourne shell is available, and a basic make, and that make is a good way to build projects. All of those are questionable, and certainly if you get rid of the assumption that you're only allowed to use ancient tools, you could immediately make autotools better, if only by removing all the shell cruft. But then someone will complain because your project doesn't compile on SunOS 4 or whatever. * Familiarity: When I'm packaging your project for Fedora, I will not be pleased if you've used some obscure or half-assed build system. If you're using autotools, I may dislike it, but at least I can fix things. The second one is a difficult one, because until your build system gets popular, it will never be familiar, and us packagers will keep cursing you. Once it's popular, it'll probably be quite crufty because it has had to handle all the horrible corner cases that autotools can do now.
MichaelMoser123 11y ago
GNU make has macros too, but these were added much later than 1991; Interesting if make macros were available earlier, would people have used them instead of autotools ? Thank you for the link on autotools, i will try to apply it if i am ever forced to do something with autoconf/autotools.
- adekok 11y ago
  GNU Make macros can't really replace "configure". They can replace "automake". I've never understood why anyone thought automake was useful / sane. Going back 20 years, a few carefully written GNU Make rules were (a) simple, (b) understandable, and (c) portable. Automake was more work for me than just writing GNU Make rules.
- david-given 11y ago
  Trying to do anything non-trivial in GNU make macros is the most bewilderingly awful programming experience it is possible to have. They are horribly broken in every respect, from little stuff like awful syntax (whitespace is insignificant except where it's significant!) and poor error checking (detecting undefined variables? Who cares?) to the really big stuff (can't do arithmetic, despite having core functions which take numbers as arguments!). A while back I wrote a compiler which targeted GNU Make and made it run Conway's Game of Life (complete with hand-tooled arbitrary precision maths library written in make). I learnt more about this stuff than is healthy to know. The compiler output is... special. http://cowlark.com/2013-10-19-insane-make http://cowlark.com/2013-10-19-insane-make
  - scrollaway 11y ago
    Fun story, I have a set of scripts that extract, decompile and process various sets of files, outputting them into a build directory. At first I wrote shell scripts to automatically do all this, then I figured this is the sort of thing Make was built for (right?). This is what I ended up with after days of work: https://github.com/HearthSim/extract-scripts/blob/master/Makefile https://github.com/HearthSim/extract-scripts/blob/master/Mak... Turns out, Make kind of just assumes you're building a C project and makes a lot of further assumptions which made writing this Makefile a living hell. In the end, I didn't even manage to do proper checks for built files. Make seems like a really poorly execution of a good concept. I think a large part of why autotools suck also comes from that.
zuzun 11y ago
If you want to get started with autotools, try to build yourself a minimal autotools project. Once you have a working stub, you already took the biggest hurdle. You only need to focus on two files: configure.ac, where you check for features, and Makefile.am, where you list your build targets and their sources. You can also write normal Makefile rules there. After editing these files, run `autreconf -fi` to create/update the configure and Makefile script. Then run ./configure make to build your project. Have a look at Appendix A/Basic Autotoolization on the submitted website or checkout libabc by Poettering/Sievers: 1. https://autotools.io/whosafraid.html#idm117385102076160 https://autotools.io/whosafraid.html#idm117385102076160 2. http://0pointer.de/blog/projects/libabc.html http://0pointer.de/blog/projects/libabc.html
akerro 11y ago
http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system http://freecode.com/articles/stop-the-autoconf-insanity-why-...
hendry 11y ago
Please please please do not use ./configure aka autohell. Study the Makefiles in http://git.suckless.org/ http://git.suckless.org/ Straightforward & fast.
- coherentpony 11y ago
  Autotools solves the problem of having to write a makefile for every platform and also provides all the expected targets without having to write them all yourself.
  - hendry 11y ago
    There is no need to write a Makefile for every platform nowadays.
notacoward 11y ago
This looks like a really useful guide through autotool hell, which is a fantastic thing to have, but it's not clear what myths are being busted so the name seems like a bit of a misnomer. Perhaps "Autotools Life Preserver" or something would be more accurate.
chris_wot 11y ago
Oh brother... this would have been good when I was developing in LibreOffice!
dankohn1 11y ago
Could anyone speak to why you would use Autotools today in a new project rather than gyp [0] (created by the Chrome team because Autotools sucks) or waf [1]? How many people really have a requirement to support more than just Windows, OS X, and Linux? I can understand not wanting to rip out a working Autotools implementation of a legacy project, but it's greenfield use should decline to zero. [0] https://gyp.gsrc.io/ https://gyp.gsrc.io/ [1] https://github.com/waf-project/waf https://github.com/waf-project/waf
- kazinator 11y ago
  autotools isn't mainly a build system; it's a system for preparing a program which will self-configure and build in various systems. Those systems themselves do not have any special tools installed. No Autotools, no GNU-anything. Autotools was intended to solve the problem of how to give the same tarball of code to a user of SunOS 4, Ultrix, HP-UX 8, and so on, such that each of those users could just unpack the tarball, run ./configure and then make. (Using the make that came with their OS, not CMake, not GNU Make, not gyp and so on). Some of the requirements don't hold as much any more; you can rely on newer POSIX shell features in a configure script, and GNU make is more widely available and so on, but the basic idea is solid: no requirement for any exotic build system just to get the program running. It's the implementation that sucks in Autotools. The high level ideas are solid.
- hp 11y ago
  Historically they have supported a lot of things the others didn't or didn't easily support: cross-compilation, changing the prefix/libdir/datadir, creating tarballs, "distcheck" to automatically check the tarball works, libtool, etc. Also lots of Linux tools are built around autotools, for example it's much much easier to rpm-ify or deb-ify an autotools tarball. Another example, there's gettext integration for autotools, automated tools for translators might rely on autotools, etc. I'm probably listing the tip of the iceberg as far as network effects. In the Linux/Unix world, autotools is (or at least historically was) what everything and everybody knows how to deal with, and non-autotools is annoyingly nonstandard. Your gyp link there says for example that its main goal is IDE support; a total non-goal for autotools. Unix/Linux C developers largely do not use IDEs. And the autotools goals probably aren't in gyp's list of priorities. So while they both "build the project" they have pretty different goals. The autotools goals don't always make sense anymore. For example the historical idea that the shipped tarball would only depend on POSIX sh and not on any other binary made a lot more sense when people were hand-compiling stuff on their HP-UX than it does today where most binaries come from distributions. If you're building a package mostly for Linux and maybe OS-X-as-Unix-compatible, especially one in C/C++ and open source, autotools probably still has a lot to recommend it.
jokoon 11y ago
I confess that I don't even know how to write a makefile, but reading the comments here, should I understand that cmake is better than autotools? Or should I learn autotools instead of cmake? Since cmake is more adopted, isn't cmake better ?
- GFK_of_xmaspast 11y ago
  If you have a need for this kind of thing, learn cmake. If you don't have a need for this kind of thing, consider yourself lucky.
J_Darnley 11y ago
Just what I want, a 900KiB configure file that doesn't even work. I'm looking at you lame! And then a make process that doesn't STFU!
jheriko 11y ago
there is only one myth that needs busting. that these tools solve any real problems that can't be solved better.

90 points by nbaksalyar 11y ago

One of the first lines "...the language used to write the configure.ac is called M4sh, to make clear that it's based off both sh and the macro language M4. " Tip: don't use Autotools

davexunit 11y ago
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
deleted 11y ago
[deleted]

DasIch 11y ago

Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.

wyldfire 11y ago
Well, is that really fair? autotools' scope is great, like you concede. But it was designed around 1991, right? > That everyone else just kind of seemed to go with it There was nothing else better available, and this was effective -- is effective. If you haven't seen the effect of momentum in software, then this is nothing. Look at how x86 systems get bootstrapped; look at how we interact with important platform devices like the RTC (I/O ports). Virtually none of this has changed because it doesn't introduce significant limitations in operating systems or hardware but it's downright odd.
to3m 11y ago
cmake is pretty bad, too, though at least it runs on Windows. (And I don't think it's got quite the same goals as Autotools, though their scopes overlap in many respects.) I've never met anything build-related, scope large or small, that wasn't somewhere between "PHP" (horrid, workable if you're careful, will rot your brain in the long run) and "Cthulhu" (beyond evil, insofar as normal human modes of comprehension can be said to apply). I wonder if this is some kind of, like, Heart of Darkness shit.
Aissen 11y ago
The big problem is that no one did a better solution. All alternatives are missing one or more crucial features of the autotools (most prominent being portability). And that is sad as well.
- rwmj 11y ago
  Cross-compilation is another. When I was building packages for the Fedora MinGW (Windows cross compiler[1]) project, it was mostly trivial to get things working if the package used autotools or cmake, and an impossible nightmare for everything else. [1] https://fedoraproject.org/wiki/Features/Windows_cross_compiler https://fedoraproject.org/wiki/Features/Windows_cross_compil...

falcolas 11y ago

While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.

riffraff 11y ago
there _is_ a huge amount of smart folks who worked or works on build systems. Sadly, it seems everyone is 80% better than the others in something and 20% lacking in something else. For example, the SCons wiki has some interesting comparisons. https://bitbucket.org/scons/scons/wiki/SconsVsOtherBuildTools https://bitbucket.org/scons/scons/wiki/SconsVsOtherBuildTool...
- wyldfire 11y ago
  I really liked SCons, but it seems like it never really hit critical mass. Ubiquity is important for a build tool.
humanrebar 11y ago
Doesn't CMake count as a successor?
- rwmj 11y ago
  I think more like "differently bad". However of all the build systems out there (and as a Fedora packager, I have had to deal with many), I'd prefer if you used either autotools or cmake, because those are the ones we're most familiar with and we can fix things.
rwmj 11y ago
Of course there are many alternatives (of the alternatives, I can only really recommend cmake). The problems broadly speaking are: * Assumptions: autotools assumes that only a basic Bourne shell is available, and a basic make, and that make is a good way to build projects. All of those are questionable, and certainly if you get rid of the assumption that you're only allowed to use ancient tools, you could immediately make autotools better, if only by removing all the shell cruft. But then someone will complain because your project doesn't compile on SunOS 4 or whatever. * Familiarity: When I'm packaging your project for Fedora, I will not be pleased if you've used some obscure or half-assed build system. If you're using autotools, I may dislike it, but at least I can fix things. The second one is a difficult one, because until your build system gets popular, it will never be familiar, and us packagers will keep cursing you. Once it's popular, it'll probably be quite crufty because it has had to handle all the horrible corner cases that autotools can do now.

MichaelMoser123 11y ago

GNU make has macros too, but these were added much later than 1991; Interesting if make macros were available earlier, would people have used them instead of autotools ? Thank you for the link on autotools, i will try to apply it if i am ever forced to do something with autoconf/autotools.

adekok 11y ago
GNU Make macros can't really replace "configure". They can replace "automake". I've never understood why anyone thought automake was useful / sane. Going back 20 years, a few carefully written GNU Make rules were (a) simple, (b) understandable, and (c) portable. Automake was more work for me than just writing GNU Make rules.
david-given 11y ago
Trying to do anything non-trivial in GNU make macros is the most bewilderingly awful programming experience it is possible to have. They are horribly broken in every respect, from little stuff like awful syntax (whitespace is insignificant except where it's significant!) and poor error checking (detecting undefined variables? Who cares?) to the really big stuff (can't do arithmetic, despite having core functions which take numbers as arguments!). A while back I wrote a compiler which targeted GNU Make and made it run Conway's Game of Life (complete with hand-tooled arbitrary precision maths library written in make). I learnt more about this stuff than is healthy to know. The compiler output is... special. http://cowlark.com/2013-10-19-insane-make http://cowlark.com/2013-10-19-insane-make
- scrollaway 11y ago
  Fun story, I have a set of scripts that extract, decompile and process various sets of files, outputting them into a build directory. At first I wrote shell scripts to automatically do all this, then I figured this is the sort of thing Make was built for (right?). This is what I ended up with after days of work: https://github.com/HearthSim/extract-scripts/blob/master/Makefile https://github.com/HearthSim/extract-scripts/blob/master/Mak... Turns out, Make kind of just assumes you're building a C project and makes a lot of further assumptions which made writing this Makefile a living hell. In the end, I didn't even manage to do proper checks for built files. Make seems like a really poorly execution of a good concept. I think a large part of why autotools suck also comes from that.

zuzun 11y ago

If you want to get started with autotools, try to build yourself a minimal autotools project. Once you have a working stub, you already took the biggest hurdle. You only need to focus on two files: configure.ac, where you check for features, and Makefile.am, where you list your build targets and their sources. You can also write normal Makefile rules there. After editing these files, run `autreconf -fi` to create/update the configure and Makefile script. Then run ./configure make to build your project. Have a look at Appendix A/Basic Autotoolization on the submitted website or checkout libabc by Poettering/Sievers: 1. https://autotools.io/whosafraid.html#idm117385102076160 https://autotools.io/whosafraid.html#idm117385102076160 2. http://0pointer.de/blog/projects/libabc.html http://0pointer.de/blog/projects/libabc.html

akerro 11y ago

http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system http://freecode.com/articles/stop-the-autoconf-insanity-why-...

hendry 11y ago

Please please please do not use ./configure aka autohell. Study the Makefiles in http://git.suckless.org/ http://git.suckless.org/ Straightforward & fast.

coherentpony 11y ago
Autotools solves the problem of having to write a makefile for every platform and also provides all the expected targets without having to write them all yourself.
- hendry 11y ago
  There is no need to write a Makefile for every platform nowadays.

notacoward 11y ago

This looks like a really useful guide through autotool hell, which is a fantastic thing to have, but it's not clear what myths are being busted so the name seems like a bit of a misnomer. Perhaps "Autotools Life Preserver" or something would be more accurate.

chris_wot 11y ago

Oh brother... this would have been good when I was developing in LibreOffice!

dankohn1 11y ago

Could anyone speak to why you would use Autotools today in a new project rather than gyp [0] (created by the Chrome team because Autotools sucks) or waf [1]? How many people really have a requirement to support more than just Windows, OS X, and Linux? I can understand not wanting to rip out a working Autotools implementation of a legacy project, but it's greenfield use should decline to zero. [0] https://gyp.gsrc.io/ https://gyp.gsrc.io/ [1] https://github.com/waf-project/waf https://github.com/waf-project/waf

kazinator 11y ago
autotools isn't mainly a build system; it's a system for preparing a program which will self-configure and build in various systems. Those systems themselves do not have any special tools installed. No Autotools, no GNU-anything. Autotools was intended to solve the problem of how to give the same tarball of code to a user of SunOS 4, Ultrix, HP-UX 8, and so on, such that each of those users could just unpack the tarball, run ./configure and then make. (Using the make that came with their OS, not CMake, not GNU Make, not gyp and so on). Some of the requirements don't hold as much any more; you can rely on newer POSIX shell features in a configure script, and GNU make is more widely available and so on, but the basic idea is solid: no requirement for any exotic build system just to get the program running. It's the implementation that sucks in Autotools. The high level ideas are solid.
hp 11y ago
Historically they have supported a lot of things the others didn't or didn't easily support: cross-compilation, changing the prefix/libdir/datadir, creating tarballs, "distcheck" to automatically check the tarball works, libtool, etc. Also lots of Linux tools are built around autotools, for example it's much much easier to rpm-ify or deb-ify an autotools tarball. Another example, there's gettext integration for autotools, automated tools for translators might rely on autotools, etc. I'm probably listing the tip of the iceberg as far as network effects. In the Linux/Unix world, autotools is (or at least historically was) what everything and everybody knows how to deal with, and non-autotools is annoyingly nonstandard. Your gyp link there says for example that its main goal is IDE support; a total non-goal for autotools. Unix/Linux C developers largely do not use IDEs. And the autotools goals probably aren't in gyp's list of priorities. So while they both "build the project" they have pretty different goals. The autotools goals don't always make sense anymore. For example the historical idea that the shipped tarball would only depend on POSIX sh and not on any other binary made a lot more sense when people were hand-compiling stuff on their HP-UX than it does today where most binaries come from distributions. If you're building a package mostly for Linux and maybe OS-X-as-Unix-compatible, especially one in C/C++ and open source, autotools probably still has a lot to recommend it.

jokoon 11y ago

I confess that I don't even know how to write a makefile, but reading the comments here, should I understand that cmake is better than autotools? Or should I learn autotools instead of cmake? Since cmake is more adopted, isn't cmake better ?

GFK_of_xmaspast 11y ago
If you have a need for this kind of thing, learn cmake. If you don't have a need for this kind of thing, consider yourself lucky.

J_Darnley 11y ago

Just what I want, a 900KiB configure file that doesn't even work. I'm looking at you lame! And then a make process that doesn't STFU!

jheriko 11y ago

there is only one myth that needs busting. that these tools solve any real problems that can't be solved better.