I work for a very large organization with a huge code-base.
Our main platform is IRIX and we use custom build tools and scripts.
They look like some sort of extended makefiles with a slightly different format, structure and keywords (but the concept is the same).
When I pushed vslick into our organization i had to write a perl script that recursed into our source tree and parsed each "makefile", then generated appropriate vslick projects and workspace files.
(I created xml templates of vslick projects and just filled them with the files I found inside each makefile)
My script is very specific for our code base though.
However, I do want to point out some of the problems with this approach:
1. Makefiles and the likes, generally do not list all source files - particularly header files.
They generaly do list all C/C++ Source files (which in turn use include statements to pull their required headers).
So a better solution would also have to parse the C/C++ source files and add files found there to the project list.
Another problem would be,
2. That you'll also have to keep some sort of dictionary for PATH variables.
for instance, our "makefiles" include other makefiles which define variables who are used as paths.
like: IMAGING_LIBRARY/main.cc
where IMAGING_LIBRARY can be defined under a different makefile (from the currently parsed) like:
IMAGING_LIBRARY=PLAT/img
and in some other file you'd find:
PLAT = /src/plat
I had to parse the makefiles, gather symbols, create a dictionary (a hash table is the most suited) and then dereference the appropriate paths.
It takes about a week and a half to write a rudimentary version and another month to polish it and fix bugs.
This approach is suitable if your organization is willing to dedicate 1 person for approximately 1 month for this task.