proposal: lazy compilation model for compiling binaries

OlliP jeti789 at web.de
Mon Jun 24 01:52:47 PDT 2013


This is now a bit confusing to me. I just made up my mind to go
with D instead of Go, because Go is too simplistic in my opinion.
Furthermore, calling C from D is a lot easier than from Go. And
now this ... I have too little understanding of D to see what the
impact of this build time issue is. Does this mean build times
come close to what they are in C++ or is this issue only about
builds not being as fast as the D people are used to ..?

Thanks, Oliver


On Saturday, 22 June 2013 at 04:45:31 UTC, Timothee Cour wrote:
> A)
> Currently, D suffers from a high degree of interdependency 
> between modules;
> when one wants to use a single symbol (say 
> std.traits.isInputRange), we
> pull out all of std.traits, which in turn pulls out all of
> std.array,std.string, etc. This results in slow compile times 
> (relatively
> to the case where we didn't have to pull all this), and fat 
> binaries: see
> example in point "D)" below.
>
> This has been discussed many times before, and some people have 
> suggested
> breaking modules into submodules such as: std.range.traits, etc 
> to mitigate
> this a little, however this requires people to change 'import 
> std.range'
> to 'import std.range.traits' to benefit from it, and also in 
> many cases
> this will be ineffective.
>
> B)
> I'd like to propose something different that can potentially 
> dramatically
> reduce compile time/binary size, while not requiring users to 
> scar their
> source code as above.
> ....


More information about the Digitalmars-d mailing list