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.
FWIW when I tried out qmake for a toy c++ project, it's the first make tool for c++ that actually just worked[1] for a simple command-line app. CMake works too, but not without fighting the horrible syntax of CMake first. And make... well it works, but at what price to your soul? ;-)
[1] The documentation is actually a little dense, as qmake is a tool capable of building "real projects", but I found that a simple qmake -project && qmake && make (I think, at least you need a project file, and the let qmake make a makefile, and then use that...).
At last, I find someone who uses qmake on HN. I've been using qmake for 4 years now. At first I started experimenting with it for a small project. The learning curve was quick and eventually fell in the comfort zone it created.
Now I use it for large scale C++ projects and I've never looked back for other build tools, not even CMake.
Surprisingly, I never understood why KDE project that uses the complete Qt ecosystem doesn't use qmake but rather settled to CMake.
Does qmake deal with finding the dependencies and automatically adding the include paths, libraries, etc. for them?
As far as I know, you need to stick the compiler and linker flags manually into qmake, which basically means that it works on your machine, but may break on anyone else's system. This is what a lot of the complexity inside cmake is addressing - differences in build environments.
I think the answer is: "It depends.". From some searching, it looks like cmake has better cross-platform support, and is (unsurprisingly) more powerful when you need to do something a little gnarly. That said, it appears (never had need to test) that qmake works fine with pkg-config:
In my experience (mostly from compiling from upstream source, when something isn't available in Debian and/or backporting for personal use) there are different kind of libraries, some behave better than others (eg: easy to install under $HOME/opt with xstow -- as I prefer to /usr/local, as the latter needs root and/or rw-privileges on /usr/local). I've yet to find any pattern for when things just work, and when things don't (the real reason typically being some hard-coded paths or other nastiness -- I just mean some obscure projects work fine, some big ones fail miserably). So I guess YMMV -- but for now, qmake is the tool for building simple c++ I've found that is simple, for simple projects. I also use CMake (preferably with ninja) -- but I don't really like the CMake "language". Maybe what we need is a CMake-generator? Then we can generate CMake-files that generate ninja files that build our code! ;-)
I've had good results with qmake, too, but I don't know how well it works for large projects. I don't think any of the codebases I've used it on was > 100,000 LoC.
What do you recommend? Autotools, bespoke shell scripts, or something else entirely?