Window's Makefiles

[Ben Hyde <bh...@gensym.com>]

Rules I'd propose:

 - Changes to the unix makefiles should have
   a simultaneous change in the NT makefiles.
   This is the responsibility of the all developers.
   If you break the NT makefiles then:
     a) don't sweat it, we forgive you.
     b) one of the NT developers will make
        a best effort to step up and kindly
         help fix the breakage.

 - NT makefiles are maintained by hand, not by
   emitting them from the Developer's studio.

 - A best effort is made to keep the NT project
   (aka .DSP) files in synch with the unix
   makefiles, but as this requires significant 
   NT expertise they sadly will often lag behind.
   This is the responsibility of the NT developers.

Discussion:

In my shop we have never been able to get sufficient
craft knowledge under our belts to let the
Dev. Studio generate our makefiles for us.  So we
write them by hand.  It's a rule that you commit 
makefiles as a set.

You want makefiles if your going to automate the
build.  In house we build within minutes of a
commit.  It's sad to break the build, but we
consider it an accepted fact of life.  Of course
breaking the build creates a high priority task to
fix it.

Yes, it is possible in principle, to let the Dev.
Studio generate the makefiles for you.  We find this
doesn't work for us.  We had problems with QA
surprises due to developers tinkering with settings.
We had problems with absolute pathnames appearing in
the files.

So we've found is best if the makefiles are
maintained by hand.

Either way the dsp files and the makefiles want to
stay in synch.  We have lots of trouble with that,
and have had live with some roughness in the
solution.

It is impossible to get a set of dsp files that
everybody in a development group can share.  People
just need to tinker with things.  It's hard to debug
code in DLL's so people move it into the core code.
Mortals can not get a set of PC configured identically,
etc. etc.

It is very nice to have a set of dsp files people
can use to get started.  So we check in a set just
for that purpose.  People use them to get going, but
very quickly find that CVS want's to check in their
tinkering - we tell them "DON'T, PLEASE DON'T!"

When the build topology changes we let somebody
carefully revise these starter DSP files.  This
takes a "select" individual.  The the DSP files seem
to often get an absolute pathnames in them, and then
they are kind a useless for other users.

The cost of good DSP files is high, the advantage is
it quick starts developers.  I often am tempted to
forgo the benefit.

I have a dream that somebody someday will write
the perl script to generate useful dsp files.

 - ben (the long winded one).