[Home] [Main] [Features] [Wish List] [News] [Documentation] [Downloads] [Fun Stuff]
(These hard-coded links are provided for babel.altavista.com browsers, as my JavaScript navigation on the left side bar is not translated by babel.altavista.com.)


So OK, what is MidWatch and what makes me think it is so special?

MidWatch is an automated build engine for compiling large scale Visual C++ products in the Win32 environment. Currently, it intergrates with Rational's ClearCase, and while Rational has plent of build tools that go with its suite of products, MidWatch does something a little different.

For MidWatch, the basis of the build is the Microsoft Developer Studio Project file. (.dsp file)

Why the .dsp file ? Can't the Microsoft IDE export to a .mak file?
Of course it can, but who should export the .mak file?
Is that the responsibilty of the developer or the Build Meister?
If you leave up to the Build Meister, he has to load the .dsp anyway to export the .mak file. So why do it?

The primary assumption of MidWatch is that the Win32 developer will want to stay within his native environment and that is likely to be the Microsoft IDE.  The aim of MidWatch is to reproduce the developer's environment exactly.

In the development teams I've seen, there are usually more developers than Build Meisters, and developers are fond of saying "Well, it builds on my machine."  Often, a Build Meister joins a project after significant code has been written, and the building of that code has become too much for the developer(s) to manage.  So a Build Meister gets hired to clean up a mess in progress.  Well, that's happened to me twice and that's how MidWatch got developed.

So there you are, one person against 30 developers who already like the way they do things, and are going to resist your effort to change thier comfortable practices. Well, this all comes from the fact that writing software is complicated now-a-days, and developers are busy with thier own specialty, software can be fragile when it is in development.  If it builds on many machines, even if you have a complicated build process, you may get the "don't fix it if it ain't broke" response.  Which brings me to 3 apropos quotes on the subject:

Please take that last one with humor that was intended!

So you have to publish a build standards document, a list of do's and don'ts that could cause the build to crash if not headed. I'll get one up here "soon", as MidWatch, while it tolerates a lot, does have limits.

I also have some recomendations to avoid filename clashes with your include files. In the past two years I have supported two different products each with more than 10000 files and each with well over a million lines of code. Sometimes developers like to use file names that others have used like "ReTryLogic.h" or "SmartPointer.h"