This improvement would be really welcome - I'm trying to use vs-android with a 
source code base of over 1000 c++ files. Do you have any pointers for how to go 
about it - I might be able to find some time to look into making the required 
changes. From my limited knowledge of MSBuild it parallelises the building of 
independent projects but not of individual build tasks within a project. So 
presumably the collection of source files to build is being treated as a single 
project and each individual build task is happening in sequence. Since VS 
itself manages to parallelise compilation there must be some way around this, 
perhaps treating each build task as its own MSBuild project?

I believe Microsoft's CL compiler handles the multithreaded builds within the 
C# compilation task.

vs-android has it's own compilation task written in C#, where this could 
potentially be implemented. It'd need to create a thread for each instance of 
the g++ compiler.

The biggest gotcha though is with the MSBuild scripting. For vs-android I sent 
each compilation unit one-by-one to the C# task. For Microsoft CL, they send 
them as a big batch, such that the C# task can farm them out to multiple 
threads.

So it'd require pretty fundamental changes to the MSBuild script. The part 
where it gets trickier is where you can potentially override individual .c/cpp 
files with specific compiler options. Dealing with that in the mix, makes it a 
difficult problem to solve.

Unity builds might be a short-term solution (hack) to your compile times:
http://cheind.wordpress.com/2009/12/10/reducing-compilation-time-unity-builds/

I've used them extensively in the past for big game projects, but they do have 
their downsides.

Issue 67 has been merged into this issue.

Here's my hacky first attempt at enabling this. I changed the foreach in  
CompileWithGCC to a parallel task, and fixed up the non-thread-safe bits (at 
least, the ones that I spotted). It appears to do the job, maxing out all my 
cores, but unfortunately it's screwed up dependency checking in some cases 
(specifically, if a files fails to compile, it won't attempt to recompile that 
file next time around). There's also a minor issue with spurious newlines being 
inserted into the output.

Does this at least look like the right direction to take? I'll continue to look 
at the dependency issue myself.

By the way, I've also made a small modification to install.cmd which kills any 
MSBuild processes if the plugin is already installed, as otherwise the DLL 
cannot be over-written.

Fixed the spurious newline issue by changing line 244 to:

string[] lines = output.Split(new Char[] { '\n', '\r' }, 
StringSplitOptions.RemoveEmptyEntries);

Apologies for the continual spamming, but I want to keep this up-to-date...

I think that the dependencies issue is present in the release version. You can 
test it quite easily thus:

1) Build the san-angeles sample
2) Add #error to the top of importgl.h
3) Build again. You should see something like the following output:

1>  demo.c
1>  C:\work\vs-android_samples\san-angeles\CppSource\demo.c(30): includes this 
header: 
1>C:\work\vs-android_samples\san-angeles\CppSource\importgl.h(28,2): error : 
#error
1>  File C:\WORK\VS-ANDROID_SAMPLES\SAN-ANGELES\CPPSOURCE\IMPORTGL.C is missing 
it's .d file: C:\work\vs-android_samples\san-angeles\Android\Debug\importgl.d

4) Build again. The dependency check will be incorrect and you will just get 
this:

1>------ Build started: Project: san-angeles, Configuration: Debug Android 
------
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

I'm going to see if I can fix this myself, although I am a complete C# and 
MSBuild noob, so I'm not very confident. I *think* it's just a case of 
correcting the tlog files when the .d is missing or empty.

Okay, I think I've fixed the dependency issues. It now tracks the result of 
each compilation task, and only adds them to the tlog if they have succeeded.

I've also fixed up the parallelisation to use the correct way of breaking out 
of a parallel foreach, and locked the output to avoid interleaving of error 
messages.

I suppose we ought to make the parallelisation optional, but aside from that I 
think this satisfies all the requirements.

Bah, looks like my implementation hangs if there are too many error lines. A 
quick fix is to do p.StandardError.ReadToEnd() before 
p.StandardOutput.ReadToEnd(), since it's much more likely that it'll fill up 
stderr first. However, I probably ought to be doing:
http://stackoverflow.com/a/7608823

Okay, here's a version with the stderr/stdout overflow handling fixed.

Thanks for looking into this, sounds very promising!

Yeah, when I integrate this (eventually, it'll be at least a couple of weeks - 
it's GDC time), I'll put the parallelisation on a BoolProperty.

Thanks again!

I am not sure if somebody else tested this updated GCCCompile.cs code, but just 
for the record, I just tested and worked perfectly!

Thanks a lot!

Sorry, had to shelve adding this one for now. I'll put it in the next release.