I'm not the first person to observe this fact, but someone should shout from the roof top that the whole auto* build system just sucks. It is not just a problem of the build system. The language is also partly responsible, too.
C/C++ is surprisingly non-portable. Header files are located in many different system dependent locations. So does the libraries. Sometimes, the function names are slightly different, or the way they are declared is slightly different. Sometimes they are in different header files.
It takes at least a few hundreds lines of #ifdef-s to get a reasonable portability, and even then it will never work on all the possible Unix platform flavors. Auto-tools are designed to help you cope with this, but the very fact that you need a tool to do it shows how devastating the situation is.
And even worse, auto-tools aren't easy to use, either. a tool generates a script, which generates another script. Now are you supposed to modify configure.in? Or was it Makefile.am? Makefile.in? config.h? When you are just trying to build your 1000 line application, this is way too much complexity.
In contrast, think about other modern languages, such as Java, C#, Python, and/or Ruby. All of them have well standardized sets of standard libraries that are guaranteed to be at the specific locations. There is much less platform dependency involved, and certainly there's hardly any platform dependency in the build process. There's no need for "./configure" at all. Bye bye autotools.
This is just one of the million cases where C/C++ drag dow your productivity down. While C/C++ is indeed necessary for some poeple, most of the applications/libraries should have nothing to do with C/C++.
Please stop this madness.