> probably the sanest thing is to go with the automake-like approach of > one .d file per .c file, which then can be annotated without having to > write logic to parse a big dependency file and update it in place.
The problem with .d files is that there's no good automatic way to deal with headers that get renamed or deleted; the dependency on the old file is listed but there's no way to make that file. Although something in the back of my head says that gnu make knows how to deal with this now. > Beyond that, cpplib internally could be made more efficient for this > task. A simple thing you can do: FYI libiberty has a dumb perl script that generates its dependencies. It's not as flexible as cpplib, but it makes assumptions that are safe to make because it knows how libiberty is coded. It might be interesting to compare that script to libcpp to see if it hints at faster processing.
