Why I hate autotools
- Myth 1. Autotools isolate programmer from platform software.
-
Do you ever try to build some real project with autotools (with ./configure)
with some compiler different from gcc? I do. I spent much more time to
say what compiler name I need, what options I need, what options I don't
to see, etc. etc. then for code portability itself! I.e. I spent more
time to boring tools that was intended for screen portabilty problems.
This problem even worse. Autotools incompatible between versions of autotools. When automake installed on you system too old for one project, it too new for another. It's a big luck when only warning happens. - Myth 2. Autotools help to write portable code.
- The case when platform A has function with name foo, platform B has function with name boo, that implement the same paradigm as foo on platform A. Programmer should worry about paradigm difference youself, autotools can't help too much here. Really I can say: 'my code work on platform A' only if I at least compile it for platform A. Or at least check the difference between platform A and platform B, if I know what happens on platform B. Autotools don't magically provide workarounds for platform A. I, as programmer, should know about platform A speciality, and should worry about it.
- Myth 3. Autotools provide easy-to-use build system.
- Well, while you use autotools only to build projects:
./configure && make && make install
all fine and you happy. Nice! But if you developer, not all so good:autoreconf ... ./configure ... make ... Boom! make clean ... Boom! make distclean ... autoreconf ... automake ... ./configure ... make
Hmm, I should pass -DUSE_FEATURE_BOO=2 for program boo!make distclean; autoreconf && automake && ./configure && make
Ufff...
It very annoying, especially if I know that all this job may be done within make tool only, without other bloated scripts.
What about this checks:checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no
when I have no fortran code? Note, that this check may be not only annoying, but block build on insignificant check.
What instead?
First, let's say that informing about and passing specific configuration options 'configure' do well. But this not require shell script 700K in size.
Then, we can see that 'make' and friends is very power tool. Just let's allow do it job well!
You have 'common' flow, i.e. compile object files from C source, link the set of object files into executable or shared object. And, sometimes, you need original operations, like generation of C file from some meta-language with some tool. Build system provide easy suggestion for common tasks, and allow you do original builds as you want. I.e. build system may worry about transformation from file.cc to file.o to file.so, take into account dependency and generate TAGS for emacs. If you don't want here something else, of cause.
As simplest example, I use two files to build xmt library on a wide set of platforms:
# -*- Makefile -*- Time-stamp: <06/11/10 16:23:01 ptr>
SRCROOT := ../..
include Makefile.inc
include ${SRCROOT}/Makefiles/top.mak
INCLUDES += -I$(SRCROOT)/include
and Makefile.inc
# -*- Makefile -*- Time-stamp: <06/11/29 01:59:50 ptr> LIBNAME = xmt MAJOR = 1 MINOR = 9 PATCH = 3 SRC_CC = xmt.cc thr_mgr.cc time.cc uid.cc SRC_C = fl.c
Really first file vary for different compilers (and very different for Redmond's nmake) but the second (Makefile.inc) is one for all.