Things I don't like about automake: It assumes control of the configuration; asserting your preferences is a battle with it. Cases in point: One package I built had a preference for one DNS library over another. Unfortunately, one of the functions it used was broken (the DNS library was a prerelease version). In another case, the package was to be shared across a cluster, where the libraries available to the workstations didn't match those of the server with the development tools. Fixing their mispreferences is difficult. You have to muck about inside configure and hardcode the value you desire, or rename libraries you don't want it to see, or other ugliness. You have to do any changes to every package as you build it. If you want to have your packages installed in /mnt/contrib instead of /usr/local, you have to specify --prefix every time. You can't just set some value in a central file and have it work. When it fails to perform as expected, it's usually difficult to figure out why. It will make a blatantly false assertion that libfoo is not installed, blaze onward on that assumption, and what exactly it's doing to determine that libfoo's missing is hidden. The "make install" that it generates is poor. Much too complex. make install runs at elevated permissions; I should be able to go "make -n install" and see just a list of "/usr/bin/install" calls so I can easily verify I'm not accidently trashing anything. With the plethora of scripts automake calls, I can't easily check what it's doing. In short, it makes the choices, you don't. Having it try to guess sensible defaults is fine, but putting its heuristics above the builder's decisions is wrong. How to fix it: configure should simply generate a configuration file, with a series of "option: value" pairs. This you can edit to suit. Then you run "make" which incorporates the options into the build. automake is already familiar with makefiles calling makefiles, so having make generate a makefile from the config file shouldn't be a stretch for it. There should be a repository of default values for well-known options. Rather than configure running feature tests for every option for every package, there would be a tool that ran feature tests and stored the results in the repository, so a) they don't have to be re-run for every package, and b) you can edit them to taste and have your preferences apply to every package. You should specify to automake a list of files to install, and it'll generate a list of $INSTALL calls. "make install" does nothing else.