GNU Autotools: A Tutorial [pdf]
If you prefer a video, you might check out my 3-part autotools tutorial, starting here: https://www.youtube.com/watch?v=4q_inV9M_us
The video shows an animation about how the autotools work (which I think helps understanding), and has a CLI demo of how to use it, all for the low price of free :-).
Today I had to use autotools for the first time, where I previously only used CMake.
I thought I should be scared, and m4 looks daunting, but what they at least get right is that it's trivial to generate both shared and static libraries, cross-compilation is a breeze, and in the end all you need is a shell to configure and make to install.
CMake defaults to either shared or static libs, and sometimes you have to read the docs for a project to figure out what custom variables influence this; and cross-compilation is almost always guaranteed not to work because some find_x cmake script tries to compile and run a C source to figure out certain properties about the target (but it confuses that with the host system).
A nice introduction how autotools work, what are the basic concepts, and what one needs to know to configure an autotools build in a standard project. Especially compared to some other build systems, it is not only solid and well thought-out but also surprisingly well documented.
Another really nice, more detailed introduction is this one:
I also highly recommend John Calcote's book "Autotools" from no starch press: https://nostarch.com/autotools2e
Probably the best technical book I bought in the last year. After the lecture, I have put aside all whispered-in prejudices and am convinced that it will still be worth betting on GNU autotools in the 2020s.
My main gripe with autotools these days is that there seems to be no standard mechanism for specifying non-standard locations for dependencies. (Or if there is, that no packages use it...) If I build something from source, it is nearly always because I want a newer version than what is available from the appropriate package repositories, which usually means that I will want newer versions of the dependencies too, or because I want a built-from-source version of one of those dependencies. If I'm really lucky, pkg-config will pick them up. Sometimes just setting LDFLAGS=-L/my/build CPPFLAGS=-I/my/build will work. Sometimes I have to say --with-gnomovision=/my/build, sometimes I will have to say --with-gnomovision-includes=/my/build/include, ...
Autotools is a pain for development. autoreconf is slow, configure is super slow, and the Makefile generated by automake is a monster that adds seconds just to do a no-op make and it is impossible to hack. So for development, I simply hack up my own scripts to generate the config headers, directly parse the Makefile.am (which is surprisingly easy to parse) and generate my own Makefile. This works well because development only need a specific environment and a simplified Makefile. But I value autotools and keep maintaining the configure.ac, because it really saves you a lot of trouble in supporting users.
Comments on value of autotools from the author of the most recent release, 2.70:
One thing that I am wondering: Why do git repos with totools build chain often include the generated files, like ./configure ?
Wouldn't it just be better to provide the source files (autoconf.ac and Makefile.am) and instruct developers to run "autoreconf" to generate the rest? That would it also make much clearer which files need to be changed if e.g. source files are added.
Or use anything else.
CMake or Meson have both learned the lessons of Autotools and so you dont need to subject yourself to them anymore.
The burning question is: is Autotools worth it these days?
In my early days of programming, I thought Autotools was the coolest thing in the whole world. It was essentially magic.
These days, with the demand for running on non-Linux UNIX at an all time low, why put yourself through all this?
Perl's build system (Metaconfig) is fairly similar to autoconf. I've always been impressed on how many disparate systems, even decidedly non-unixy ones, it handles. You can tell, though, it was a lot of work to get to that state.
After years fighting with slowness and unmaintainability of Autotools, using meson is just a breeze.
You can get it all, quickly and cleanly.