dmd 1.046 and 2.031 releases

[Tom S]

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