D2 port of xfBuild (alpha version)

[Rainer Schuetze]

On 01.12.2011 21:07, Joel Christensen wrote:
> On 01-Dec-11 11:08 PM, Andrej Mitrovic wrote:
>> On 12/1/11, Joel Christensen<joelcnz at gmail.com> wrote:
>>> Thanks Andrej. Works now. Or, I have to change how StopWatch
>>> (std.datetime) works in my programs, because putting '*.start;' twice
>>> fails an assert.
>>
>> Hmm, I'm not sure what you're referring to. Is something broken about
>> the profiler in xfBuild (it uses stopwatch), or are you referring to
>> your own code?
>
> My own code. I used '*.reset' instead of putting '*.start' in again.
>
>>> Also, it doesn't seem to work with Visual D.
>>
>> I haven't tested it with VisualD, but I'll give it some testing.
>> VisualD does have it's own builder, of course. How are you invoking it
>> / what exactly is failing?
>
> VisualD has more than one source file in the compiler arguments.
>

You could set the "Build tool" for all files but the main module to 
"None", so they will not be placed on the command line (doing it on a 
multi selection does not seem to work, though).

If I understand correctly, xfbuilds' big feature is to collect imported 
modules and only compile files that are modified or that import modified 
files, but in a single compiler run. These are linked together 
afterwards with the remaining object files.

I have considered adding such a compilation mode to Visual D aswell, but 
I don't see a large advantage to compiling the whole project because the 
import dependencies easily spread across all files like a virus. Even 
creating di interface files does not help, as you must not remove 
imports because it can ruin the order static constructors are run.

If there are natural independent groups of modules, I put them into 
libraries anyway - otherwise the compiler can run into memory trouble.

What's your experience? Does xfbuild work significantly faster than 
building all the modules like rdmd?