Not a bug - an offer of code

[Pete Randall]

Hello. This is an open letter because I don't know how many people peruse
messages addressed to bug-make. I tried mailing Paul Smith directly a
while back and Bradley Kuhn kindly suggested I try here instead.

Disregarding history and politics (these were covered in my message to
Paul, which should also be disregarded - I was less than happy when I
wrote it and there's far too much whining in it), would you be interested
in connecting make to a CM server (eg CVS) in order to do controlled
builds? As part of my work I've implemented such a thing (you can get a
fairly recent version of the source from
ftp://ftp.merant.com/download/pvcs/dimensions/misc/make-147-tier1.tgz,
but there's going to be an update in a week or so).
It's actually designed to be used with the PVCS Dimensions CM system (a
product formerly known as PCMS), but the idea was that the connector
(which is written under the GLPL, for obvious reasons) would be general
enough to be used with anything - there's no point in writing free
software that's tied to a commercial system.

So, why am I writing now?

Well, the time has come to integrate this beast (currently known as MCX)
with GNU Make 3.79.1 - it's currently integrated with GNU Make 3.74. This
presents me with a few "problems":

* For various reasons, the protocol (and the MCX implementation) are going
  to be heavily revised. Over the years the generality has been
  partly sacrificed for expediency. I want to make sure the new version
  is truly general.

* Part of the revision will include maintaining local state for the
  bills of materials to provide better sandbox support. I noticed that
  rule comparison is on the "todo" list for make. This is something
  that will be part of that local state. Rule comparison is currently a
  server side function...

* The rate of code change in GNU Make is very high, which is a good thing
  in terms of delivering what people want. However, it makes maintaining
  currency in tightly integrated extensions a (recurring) nightmare.
  Trying to reduce the risk has introduced some deficiencies, notably in
  the way implicit cotargets (my term for where a rule builds multiple
  outputs that cannot be pattern related from a single set of  inputs) and
  static libraries are handled (for a CM system to provide the best match
  from previously built libraries it has to know evaluate all the member
  dependency graphs before deciding which members should be considered out
  of date).

The simplest solution to these problems - from my point of view - is to
make "son of MCX" an "official" extension (much like r-cstms) so that
everybody can use it if they want to without having to rework the GNU Make
code.

If you download the source, you'll notice that it also implements a
Microsoft NMAKE compatibility mode. I'm *NOT* planning to put this into
the 3.79.1 integration (though I'll do it if there's any interest).

Let me know whether or not this looks like a beneficial course to you.
The work is going to be done anyway - I'd just like it avoid doing it
every few months...

Cheers,
Pete.