http://www.workspacewhiz.com/OtherAddins.html#FastSolutionBuild

I’ve never had interop problems between default DevStudio compile/link and IB compile/link. In fact, I used them pretty interchangeably when i was doing PC development. Losing Edit&Continue was a small price to pay in general, but what really killed the whole thing for me was the enormous link times. Incredibuild could do a full rebuild of this project in 6-8 minutes, plus 2 for the link. The same codebase built with multiple Jam processes on a single workstation was just as long, but with a much shorter link.

The key to sane development of course is managing dependencies. Someone actually needs to care about it from the beginning, and keep them managed throughout the project. IMO you shouldn’t really need Incredibuild at all, unless you’re doing a lot of full rebuilds for some reason (why, though?). For the incremental style of development that both Noel and I practice, though, fast linking is truly far more important than anything else.

Oh yeah, Visual Studio is a terrible code editor also. I’m not surprised that they’re rolling it into something targeting smaller applications…

It doesn’t. Or at least it doesn’t unless you write your own multiprocessor-aware C# build script. MS helpfully writes that “there is nothing to stop a custom task using multiple processors to do work.”

http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_072804b.aspx

Also, don’t expect MSBuild to handle C++. Or at least without some grief on your part. Alex Kipman, the MSBuild Program Manager, writes that “in VS 2005 (Whidbey) C++ won’t be supported natively.” There’s supposed to be some support for interoperability with C++ projects by the time the whole thing actually ships. Read his post at the bottom here:

http://www.winfx247.com/247reference/msgs/0/1868.aspx

Visual Studio seems to be becoming more and more a solution for lightweight web applet development as opposed to large-scale application programming.

We do have the multiple CPU licenses, but I didn’t know Incredibuild actually helped any with link times. It never ocurred to me that linking would be an easily parallelizable operation. But now that I think about it, all it’s doing is going through the object files and updating a bunch of function addresses based on a table, so there’s no reason why it can’t be distributed on multiple processors. Neat! Does VS 8.0 use multiple cores for linking as well?

That allows the incredibuild to use both of your logical / physical processors for linking. So with incredibuild your linking times should actually be faster if you have two procs.

Overall I agree with the article. Sometimes incredibuild fails and you need to recompile. sub 10 minutes later off you go!

And I completely agree with the position that: incredibuild hides compile issues due to poor physical dependencies. There is nothing like PUNISHING a developer with long compile times to make them look at what badness they have wrought. And compiling after every change is a good practice as you can watch the list of files being compiled in the output window and go: “Why on earth is FooBarBaz.cpp being recompiled for!!!”

>Are you using other compilers than Visual C++? Then you’re out of luck. You’ll have to come up with a totally different system to build your code for those platforms.

2.20 has beta support for intel compiler. Not Codewarrior or other console compilers but least one more

>Throw a faster machine with multiple cores (the future of PCs), and a decent build system that can use multiple threads (not MSVC, go figure)

VS 8.0 uses multiple threads

for the ‘edit and continue’ look under known issues:

http://www.xoreax.com/support_knownissues.htm#ki02