DMD 1.005 release

BCS ao at pathlink.com
Tue Feb 6 15:59:03 PST 2007


Reply to Derek,

> Thanks Walter! :-(
> 
> Bud is no longer a useful tool because it can no longer do what it was
> trying to do - namely find out which files needed recompiling and get
> only that done. Because in order to do that now, it first has to
> recursively compile each command line file and imported file using the
> -c -v switches to get a list of the potential files needing to be
> checked for recompilation. But seeing I've just compiled them to get
> this list, there is not much point now in /recompiling/ them. Also,
> mixin-imported files are not necessarily modules but must be treated
> as code fragments, so they can't be compiled to see if they in-turn
> effectively import other files!
> 
> My work here is (un)done.
> 
> It seems that DMD now needs to be enhanced to do what Rebuild and Bud
> were trying to do.
> 

If bud keep around meta data about what happened last time (building N required 
A, B, C) then if none of those changed, the set of files that can be used 
can't change. Having that kind of tree would let you do a minimal rebuild 
even with the new import stuff.

Once you go that direction (DMD would have to report the files used) why 
not have DMD report the public interface of each module? that would let bud 
notice when a change in a module doesn't demands a rebuild of the modules 
that import it. Some of this might be possible by watching for actual changes 
in .di file, not just checking modification dates.





More information about the Digitalmars-d-announce mailing list