My recent rant briefly appeared on the front pages of HN and /r/haskell, to a largely negative response. Most of the comments either accused me of having autotools-Stockholm-syndrome or insulted my reasoning ability. Since I still stand by what I said, I will respond to those main criticisms.
Autotools-Stockholm-syndrome: this argument is basically “I could
write a 20-line Makefile to build my code instead of
learning the autotools”. Yes, you probably can. Now suppose you want to
add automatic dependency tracking, so when you compile
foo.c into foo.o, gcc (and other compilers)
can list any included .h files as extra dependencies for
foo.o. Now suppose you want to support other compilers,
more OSes than just GNU/Linux (or your MacBook). Now suppose you want to
support cross-compilation. Now suppose you want to support the GNU
Makefile Conventions, including the standard
targets for users. A tool to automatically generate
makefiles starts to sound pretty good. The traditional
./configure && make && sudo make install
dance is pretty good for the user (CMake, for all its faults, wins here
with its wonderful GUI) and a properly autotooled package is quite easy
for distros to package. In the past, I’ve written hand-written Makefiles
for specific projects (often internal ones that don’t need an install
step), and it is often the way to go. For free software projects written
in a supported language, automake is an excellent (if
warty) tool. You never know quite what users are going to want to do
with your package.
Reasoning: The accusation here is that I’m appealing to tradition by
saying that libtool is allowed to wrap the C compiler, but a new tool
cannot. I maintain that wrapping the C compiler always was a bad idea to
be avoided if possible. There’s not much that can be done in libtool’s
case (especially when factoring in things like DLL support on Windows)
but a pkg-config-ish tool for GHC really would help.
There’s nothing wrong with a convenience wrapper, but as Alan Kay says,
“simple things should be simple, complex things should be possible”.
GHC’s approach covers the “simple things” but not the “complex
things”.
Saying that “your new tools should play nice with the old tools” is not an appeal to tradition. It makes no assertion about the quality of the old tools, but simply addresses a practical concern. Look at how long it took for python 3 to get going because it tried to make a clean break from the past. Working in an ideal world is nice, but supporting the real world is better for getting things done.