A case for autotools that I have only recently begun to understand

Like just about anyone who has ever had to install software from source has, I have /used/ autotools before. But like many barely ever scratched the surface. Lately I have been cuddling up with the autotools from a developer perspective, a lot more. To the point perhaps, that I am liking autotools better than I ever thought I would. Like anyone whose used more than 1% of autotools, I know you can (or are supposed to when the developer did it right) be able to run configure/make outside the source tree. Also I know about --prefix and most of the usual configure script goodness. Now, it's far from the first time that I have mentioned it, but my "Holy Grail" of builds has long been a multi-tree build:  one tree for build files, one tree for distribution files, and trees for whatever source and data files are needed. Then because I may be doing a diverse set of platforms, this usually becomes a need to further grind down into having co-existing build/dist trees: for example to have FreeBSD, OpenBSD, Linux, and Windows NT builds in the same working copy. Including using different toolsets, such as GCC 3.x, 4.x; and MSVC 9.0, 10.0 on the Windows NT builds. Now that my main computer is an ARM, processor architecture will probably end up mandatory. I like stuff like Build/platform/toolset. Hacks to keep this sort of thing working under {insert random OS here} should be kept to a minimum. How well a build system supports helping me with this problem (and file system hier) is one way that I judge build systems. Over the years, I have tried...just about everything except ant and maven but hey, how many C/C++ projects do you see using those at home? Multi-lingual stuff is always idea. At present, my favourite build system is premake4 -- it makes setting up such a build pretty painless. After that is probably Qt's qmake, since it makes compiling fairly painless. With the GNU build system, it is pretty easy to do something like:

    $ cd Build/Linux/ARMv7/gcc44
    $ ../../../../configure --prefix ../../../../Dist/Linux/ARMv7/gcc44
    $ make install

Which would give something well suited for testing, and there is a config file to save whatever configuration options I usualy test with in $prefix. The check and installcheck targets also do what I will typically do with a `make tests` or a `./tests.sh` in my own working copy. To top it off, autotools probably has one of the best tools for making a distribution: make distcheck. I do not need most of what autoconf can do, and usually prefer to skip it. The ability to have things fail at configure rather than compile time is handy. Being able to e.g. toggle between Deps/{pkg} and the systems {pkg} at configure time is great and something I already do with premake4. Automake can also pretty much do what you could get out of not having to hand write Makefiles. What REALLY shines however is libtool! We have all cursed at something or other involving autoconf, automake, or libtool. But the little secret is libtool is one of the best assets ever given to a developer. If you don't think so, you should try to alcomplish the same thing in SCONS for a solid week, just to support three platforms with differing toolsets, unless much as changed in a few years: the amount of kludges is a recipee to be pissed off. libtool can pretty much do it all and for a lot of platforms. The real question is how well autotools would really play with doing a Windows NT build with Visual C++. I've never tried that. That is also the principal reason I've never used autotools on most of my projects lol.