My summary of the article (I haven't tried it myself):
- can improve a full build compile time
- will probably slow down incremental build compile time
I have interoperability mode turned on, so I can both compile with IncrediBuild and normally.
But IB does not treat everytime in the .vcproj file as MS does. For example we used to link statically to certain libs, and later added them with the sourc code, and put dependancies in the .sln file. Well we forgot to remove the references, and guess what - MS ends up with one version, IB the other.
In our case IB was ignoring the .lib files, but taking directly the .obj files and linking with them (this has other side effects, for the globally initialized C++ objects).
But still it's time saver. We often have bad .pdb, .obj files produced, locked situations, etc.
We even use it for Makefile builds, but again such issues are popping out.
It's a clever system, that wraps the whole I/O and runs any process on a different machine, but all I/O is still done on the machine it's coming from... I wish that was somehow built in modern OS's.
But IB does not treat everytime in the .vcproj file as MS does. For example we used to link statically to certain libs, and later added them with the sourc code, and put dependancies in the .sln file. Well we forgot to remove the references, and guess what - MS ends up with one version, IB the other.
In our case IB was ignoring the .lib files, but taking directly the .obj files and linking with them (this has other side effects, for the globally initialized C++ objects).
But still it's time saver. We often have bad .pdb, .obj files produced, locked situations, etc.
We even use it for Makefile builds, but again such issues are popping out.
It's a clever system, that wraps the whole I/O and runs any process on a different machine, but all I/O is still done on the machine it's coming from... I wish that was somehow built in modern OS's.