I tried to give Automake a fair shake, I really did. But after trying it on a half-dozen non-trivial compiled projects, I have to conclude that is is more trouble than it's worth.
Why?
Automake purports to ease the burden of writing those awful makefiles. It does so by constraining you to a very specific software build discipline, rounding off all those sharp edges so that you can't accidentally hurt yourself. This saves some time, but only in one phase of the project: the beginning. With the full Autotools stack, it is almostr trivial to set up a new project.
(Note: I'm talking exclusively about software projects written in compiled languages like C. I have never tried to use Automake for anything else, but I imagine it's just as worthless.)
If you go the Automake route, you get to forget you ever saw a Makefile, and go about your day writing code for The Next Big Thing ™. Sounds great! So what's wrong with Automake again?
Let's put it a different way.
Code is hard, right? Put aside any language bias for a moment — I'm not talking about the horrors of C memory management or the problems of JVM performance. I mean that code is hard. All the high-level, garbage-collected, pointer-not-having language features in the world won't change that fundamental fact that it takes a certain mind- and skillset to decompose real-world problems into multi-layered abstractions and model them in ones and zeros.
Agreed? Okay. Moving on.
Since code is so hard, let us solve that problem. Why don't we promote more re-use? What if we could promote re-use across language barriers? What if we could promote re-use across time? If we settle on a single calling convention for bits of logic, and a standard, bi-directional transport for passing messages into and out of those bits of logic, we could make coding a ton easier.
We have that. We call it the Unix philosophy. The calling convention is execve(2). The message bus is pipe(2).
I'll just wait here while the entire world of enterprise software development, all Open Source projects everywhere, and every startup ever rewrites everyting in bash.
...
Why isn't anyone throwing out their library of Java programming books for a copy of O'Reilly's LTBS3e? Because it's ludicrous to think that bash is the ultimate programming environment because it hides complexity behind a few pipes and some execs.
Let's take a different tack.
Hell, let's switch industries for a minute.
A charcutier (one who practices charcuterie) is a butcher who deals with prepared meats like patés, bacon and sausages. It's an exacting profession requiring a depth and breadth of knowledge that blends art with science — not unlike what a hacker does with bits and bytes. Between curing, fermentation, brining, emulsification and seasoning, the charcutier has a number of highly specialized and demanding tools at her disposal.
And yet the charcutier still grinds meat to make sausage.
Don't skip the fundamentals, no matter how unpleasant they may seem. Grinding meat, like writing Makefiles, is an essential step in their respective processes, and skipping them is a disservice to their crafts.
James (@iamjameshunt) works on the Internet, spends his weekends developing new and interesting bits of software and his nights trying to make sense of research papers.
Currently exploring Kubernetes, as both a floor wax and a dessert topping.