Re: Microsoft and IDE builds

[JohnA]

----- Original Message -----
From: "Greg Spencer" <address@hidden>
> Yes, I'd like to see any good references too.  I've searched for such a
> thing before, with no luck.
The only reference I've seen is on MSDN and it is the MSVC reference. Which, is 
as you say below not for large complicated projects.

> Internally, MS considers VC++ to be a toy (iow: not for large,
> complicated projects), and they have their own home-rolled build system
> (based on an internal version of nmake) which they use for all their
> large projects (Office products, etc).
The general rule seems to be: If you have 1 - 20 projects in your "system" you 
can generally get away with just using the VC
workspace (dsw) idea. Everybody shares a dsw, changes to it are coordinated via 
sourcesafe or what-have-you, everybody's directory
structure is on the same drive, etc. Then VC is a happy product to work with. 
The nightly build is done via a command line macro
invocation to compile the workspace (rebuild all)

If you have greater than 20 or so projects, then the performance gets to be a 
drag and it is too cumbersome to deal with. So you
roll your own. In my previous job, we did an abomination of a thing where we 
sourcesafed the .dsp and .mak for each project.
(There's an option to do save the .mak automatically every time you save the 
dsp.) Then we added higher level makefiles that grouped
the many projects (~250) into subsystems and then a perl script above those to 
build combinations of subsystems in whatever way you
wanted.

The saving of the dsp and mak was done only after limping along for a few 
months trying to VC to generate the mak's from the command
line (via a macro). That technique was just too horrendously slow. Saving the 
mak's solved one problem but introduced yet another
dependency in that the mak's had to be kept in sync with the dsps now. Caused 
some problems here and there but generally worked ok.
My guess is that we were helped by the fact the system had become relatively 
stable by then and so new projects and changes to
projects were rare.

The down side of this horrid crap was that we couldn't quickly change the 
compile settings across the board (for example). So making
changes was incredibly difficult and so changes were just not done -- problem 
solved! But since there was no centralized makefile,
we ended up writing a perl script that would spew out the compile settings and 
verify that they matched our settings document.

I could go on for longer... my apologies for the long post. This is just a 
taste of the crap we went through. And since it was such
a god-awful mess, there were a lot of -- how to say it nicely -- skirmishes 
over how to do it.

MS could do a couple of things right off to save us all a ton of grief:
1) give a (fast) way to compile .dsp directly. An msvc macro can do this but 
the load time for the executable is so high that it
isn't practical.

2) give the ability to use some sort of indirection (via a global file for 
example) for compile settings and other parameters.

John