I believe that things which behave like Make, wrap it, or otherwise generate Makefiles are missing an opportunity. If you're building C or C++, that code should already specify all of its deps. You just need to stick to certain design rules.
Really, if you say "build foo", it should just figure it out. The only interesting part is if you have extra flags needed for some libs and/or headers, and those can be specified without too much trouble. Using pkg-config as a starting point usually helps.
I'm speaking from experience here. I stopped using make for my own builds a couple of months ago. Life is great.
This requires Make to parse the files in some way. What I find nice about Make is that there's no magic. I can use Make to drive builds of C, D, fortran objects and link them together, throw in some Java, transform markdown into html, generate graphs with graphviz and build pdfs with latex.
In those cases I'm positively hopeful that Make won't try to do any magic except building its dependency graph, see which files are older than their deps, and do the actions as described.
Make is no silver bullet, but it does a hell of a job at building and binding together non-ideal stuff.
Not sure how mature it is, but Ekam is a project that thinks in this direction. It's not quite as easy as you believe, but it's definitely possible. http://code.google.com/p/ekam/
There's a big note about how it only works on Linux and how FreeBSD and Mac OS support has atrophied. I take this to be related to the syscall sniffing stuff which is at its heart.
Maybe I'm just conservative, but that kind of design is not the sort of thing I would ever want to rely on.
I suspect your code may already have all of this right in the source.
#include <stdio.h>
#include <mysql/mysql.h>
#include "base/logging.h"
#include "http/cookie.h"
// ... and so on.
Right there, you can translate that into a system header you can ignore, a system header for which you should add cflags and ldflags where appropriate (compiling vs. linking), and a couple of local libraries which need to be further investigated.
http/cookie.h and base/logging.h are then analyzed, along with http/cookie.cc and base/logging.cc, assuming they exist. Any #includes there are chased down in the same manner. This continues until everything has been resolved.
If you keep track of all of these things, then you will have a list of every object file which needs to be rolled up into the final binary. You also pick up all of the flags required to compile and/or link with those things by extension.
Obviously you have to handle the whole "rebuild if something changes" thing, but that's not particularly difficult, either. I wrote my own tool to do exactly this. I'm using it for my own (C++) projects, and it's been quite pleasant. It won't work for everyone, though.
As long as every c file has an h file with the exact same name, and every lib has precisely one so file, with the same name, I tend to agree. Although I know many projects for which this is not the case.
Really, if you say "build foo", it should just figure it out. The only interesting part is if you have extra flags needed for some libs and/or headers, and those can be specified without too much trouble. Using pkg-config as a starting point usually helps.
I'm speaking from experience here. I stopped using make for my own builds a couple of months ago. Life is great.