DI File Generation

Jonathan M Davis jmdavisProg at gmx.com
Wed Dec 14 12:50:37 PST 2011


On Wednesday, December 14, 2011 21:37:14 Timon Gehr wrote:
> On 12/14/2011 09:24 PM, Adam D. Ruppe wrote:
> > On Wednesday, 14 December 2011 at 20:14:42 UTC, Jonathan M Davis wrote:
> >> Considering that you must have the bodies of functions to do either
> >> inlining or CTFE, stripping _anything_ from a .di file carries a
> >> definite cost.
> > 
> > I agree with you in general. I think the main use of .di files
> > is for closed source libraries... which means we should probably
> > go with putting as little in as possible.
> > 
> > 
> > If you want it all, use your .d files directly.
> > 
> > If you want a closed source lib, go with .di, then
> > add back only what you want to release the source for
> > (templates, ctfe functions, inline things) manually.
> 
> If a project grows sufficiently large, the possibility of having
> separate compilation is certainly important too. The compilation of my
> current project takes about 1.3s. If I compile every module on its own,
> I get a compile time of ~6s. That is because the semantic analysis of
> the code involves a fair bit of CTFE, and imported modules need to be
> semantically analyzed to a certain extent. Autogenerated .di files
> should work in a way that reduces this cost so that an efficient
> incremental compilation setup gets easy. If the autogenerated .di file
> contains the CTFE'd information, compilation gets a lot faster.

But it doesn't contain any CTFE information beyond the source code itself. 
There's no question that .di files could be improved to work better with 
regards to CTFE, but that would require redesigning .di files on some level, 
which probably can't be done for D2 at this point.

- Jonathan M Davis


More information about the Digitalmars-d mailing list