It will depends on you platform and technology. I can only recommend you to _not_ be fancy and stick with the conventions or else you could have a lot of trouble to interact with dependencies. By dependency I mean anything your program would need to run: from system libraries, headers, local libraries linked either statically or dynamically, or even syscall. A lot of things can go wrong, our whole software cathedrals are build upon years of conventions and patches. Anything can break. Don't even try too look what `ld(1)` is doing.

Autotools has never be a great tool, only a necessary evil for when you need to package cross-Unixes software. I heard that CPack (http://www.cmake.org/Wiki/CMake:Packaging_With_CPack) do the job while being exactly as good as CMake (which can be a compliment... or not. YMMV).

So, if you use Rust, use Cargo, with Java use Maven, with C# use MSBuild, with ruby use Rake, etc. And C/C++ ? Well, for once if you can chose you're lucky. You can try CMake or premake.

The only thing you must do is get away of most of the Google's build projects: Gyp, Lunch, Ninja, etc. I have horrible experiences with those. Even worse than Rubygem's native compilation, which is quite a performance.

This is a good question. After too many years experience of fighting with build systems, I have come up with one overarching requirement - the build system needs to be debuggable. I need to be able to easily identify why a particular file was built. I need to be able to easily recover the command line that builds a generated file, as in if I know that I have a source file called foo.c, I need to be able to easily obtain the command line that compiles foo.c to foo.o, so that I can see the options that were used. I need to be able to easily see how variables are constructed. Something like being able to put a watch on them, so I can find the lines of build files that modify them.

You need these things because you know what? One day someone else is going to want to modify your build system, to cross-compile for another target device, or to build a library instead of an executable, or to add a configuration option, or whatever. Or they are going to find that they need to optimise the build because it's too slow. And without these tools, those tasks are ridiculously complicated.

And lastly, it, would be wonderful if I could take an autotools or pure-makefile based project, and convert it to this system with a simple import statement - the resulting project build file wouldn't need to be particularly beautiful, because, with all those other tools that I listed above, I could clean things up by hand after the import.

The bad news is that as far as I am aware, no such tool exists. I assume it must be a hard problem to solve, because the pain that build systems cause is a real and ongoing concern for millions of developers around the world.

If you're the sort of person that writes these types of system, I would be your customer. Make the basic build system - where you can create and build projects - free, and make the debugging tools something that you have to pay for. I for one would be your customer.

All of which leads me to the bad news: I've never yet encountered a system that does these things, which is why I needed to include a plea to someone to make one.

For C++, unfortunately CMake is the best option there is it seems. For LaTeX there is latexmk. Clojure has Leiningen.

You see, it heavily depends on your preferred environment.

For C++, I'm a long-held adherent of SCons.

You can make some horrendous messes but it's nice to have Python around instead of having to learn another intermediate language as in CMake's case.