Derek Parnell wrote:
Then we can use "-deps=dep.txt -nogen" to get the dependency data so build tools can then work out what needs to actually be compiled. And in that vein, a hash (eg CRC32, MD5, SHA256) of the file's used by DMD would be nice to see in the 'deps' file. Would help build tools detect which files have been modified.
I think this should be the job of the build tool, not the compiler. For example, xfBuild uses the compiler-generated dependency files to keep track of its own project database containing dependencies and file modification times. I guess I'll be adding hashes as well :) Why a separate file? When doing incremental builds, you'll only pass some of the project's modules to the compiler so the deps file would not contain everything. The proper approach is to parse it and update the project database with it.
May I make a small syntax suggestion for the deps format. Instead of enclosing a path in parentheses, and using ':' as a field delimiter, have the first (and last) character of each line be the field delimiter to use in that line. The delimiter would be guaranteed to never be part of any of the fields' characters. That way, we don't need escape characters and parsing the text is greatly simplified.
I don't think the parsing is currently very complicated at all, but I guess YMMV. I'd argue that the current format is easier to generate and more human-readable than your proposed syntax. The latter might also be harder to process by UNIXy tools like grep or cut.
Also, simplifying the paths by resolving the ".." and "." would be nice.
Yea, that would be nice. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
