Some time back, I discussed switching a personal project of mine to using the GNU autotools. At that time, I was overall quite pleased with the GNU build system. However, in the intervening time, I have had more experience with those tools and I have since revised my opinion.
There are two things that annoyed me about the automake/autoconf system. The first is that unless your entire project is in a single directory, it strongly pushes you toward using recursive make. As long as the various subdirectories have no interdependencies, this is, of course, no problem. However, dependency issues start rearing their heads very rapidly if there is even the tiniest interdependency. That, however, is not entirely automake’s fault. I could have insisted on a system that did not use recursive make.
The second, and by for the most annoying, problem is that managing all the autoconf and automake debris very quickly started taking more time than actually developing the project. In fact, nearly all the time involved in generating a release was in making sure the correct files were included to keep autoconf and automake and friends happy.
Now, I decided I needed to get the first issue above sorted out. That meant completely redoing all the automake stuff to eliminate recursion with make. However, upon reflection, I realized my project was gaining nearly nothing from the use of automake and friends. I was using gnulib to get some portability to Windows platforms but that brought a horrible amount of bloat to the distribution and substantially slowed down build times all so I could have the convenience of using a couple of gnu extensions to libc. And gnulib insisted on being invoked using a recursive make.
Okay, so the first step was to rip automake and autoconf out of the project and roll my own Makefile system. Well, I succeeded in doing so decent results. There are some things I could have done a lot better but it works so I’ll tweak it later when I feel like it, if I feel like it. This new system does not invoke make recursively. By doing that, I avoid the problem of editing a file in one directory that should cause files in other directories to be rebuilt instead not being noticed by make. And the little bit of icing on the cake is that it builds considerably faster.
The next step was to eliminate reliance on gnu extensions. This took a bit more time because one of the extensions (argp) was non-trivial to replace. Having done so, however, yields source code that will build under a modern Linux variant as well as under the MingGW32 system.
The final bit was dealing with a few portability issues. Most notably, providing an easy way to select cross-development tools to build binaries and to handle the fact that Windows wants “.exe” on the end of executables. These turned out to be simple enough to orchestrate.
There are still a few bits that need to be added. Most notably is a scheme for packaging the entire thing up without any extraneous files. Now that the build system is sane, or at least comprehensible to a mere mortal, however, that should not prove to be much of a challenge. Indeed, it may even be possible to almost totally automate the process when the time comes!
There is, however, one downside of ditching autoconf. That is that the familiar “configure”, “make”, “make install” process of building a software package no longer applies. To build the package on a system not anticipated by the Makefile may cause some pain to the builder. Then again, there is nothing that says the person encountering problems cannot simply solve it and either send a patch back to me or not as he chooses.
Overall, I think the disadvantages of not using something familiar like autoconf are far outweighed by the advantages of a simpler build system.