GNU make suggestion: did the dependency really change?

[Henning Makholm]

Gentlemen,

I use GNU make to build a medium-sized (18 Kloc) set of programs
written in Moscow ML. It works fine, but I would like it to work
a little finer still.

Background: Moscow ML has a module system where, among other things
each module has a human-created interface definition in a file called
modulename.sig. This file is compiled to a binary modulename.ui file,
which is then read during the compilation of the module itself and
other modules that import stuff from it.

Among the things exported by a module is type definitions, and the
declarations in a .sig file can refer to type definitions exported from
another module. Such imports get resolved during the compilation of a
.sig file, such that the .ui file is self-contained. Thus, to make
a .ui file, certain other .ui files may need to be present. This may
continue for any number of levels, and we frequently have a situation
like

mod1.ui: mod1.sig           ; mosmlc -c mod1.sig
mod2.ui: mod2.sig mod1.ui   ; mosmlc -c mod2.sig
mod3.ui: mod3.sig mod2.ui   ; mosmlc -c mod3.sig

where mod2 exports a function whose type includes a type from mod1,
and mod2 also exports a type which does not depend on the type from
mod1, but which is referred to from mod3.sig

Now, suppose I change something in mod1.sig, but not the type
declaration that mod2.sig refers to. Then
 - It is, of course, necessary to rebuild mod1.ui. Its content changes.
 - Since mod1.ui now is different, mod2.ui must also be rebuilt. It
   turns out, however, that the new mod2.ui is exactly identical to
   the old one, because the *relevant* part of mod1.ui hasn't changed.
 - Now there's really no reason to rebuild mod3.ui (or anything else
   that depends on mod2.ui but not mod1.ui). But make does not know
   that, so it goes on to do a number of unnecessary compiles.

I would really like to have a make tool that could discover that
mod2.ui did not actually change when we rebuilt it.

First question: Is it correctly understood that I will have to hack
make to achieve this behavior, or is ther already such a feature
buried somewhere in the manual where I didn't guess to look?

Here's how I propose make could be amended to handle the above
situation:

1. I request special processing of .ui files by adding something like

        .CHECKCHANGE: %.ui

   to the Makefile

2. make uses its normal algorithm to decide on a sequence of commands.

3. Just before spawning the command to rebuild mod1.uo, make reads
   the previous contents of the target file, and after the command is
   completed, make checks to see whether it actually changed. If the
   file is large, some sort of checksum could be used.
     In the case of mod1.ui, the file did actually change, so nothing
   further is done.

4. The same comparison is done for mod2.ui. Sinc mod2.ui did *not*
   change, its name is inserted into a global set of "pseudo-changed"
   files.

5. Before running the commands for mod3.ui, make notices that all the
   out-of-date dependencies that triggered the command (i.e. mod2.ui)
   are marked as "pseudo-changed". So the command is not actually run,
   but instead mod3.ui is simply *touched* so that later runs of make
   will not see it as being older than mod2.ui. Also, mod3.ui is
   itself marked as "pseudo-changed".

6. The check for changed contents after running commands is only made
   for targets mentioned in .CHECKCHANGE. Checking for pseudo-changed
   dependencies before running a command is always done. All checks
   are turned off if the -W flag is used (because that is the simplest
   sensible combined semantics).

Second question: Can anybody suggest improvements to this plan?

Third question: Can experienced make hackers suggest reasons why this
would *not* be a relatively localized change to make?

Fourth question: If I can come up with a nice and tidy patch for it,
what would be the chances of having incorporated in the official make
release? I know that the FSF wants legal papers signed, and I assume
that make must be compilable by pre-ANSI C compilers, but which other
pitfalls are there to avoid?

-- 
Henning Makholm              "Det är alldeles för ansvarsfullt att skaffa en
                            flickvän. Det är ju som att skaffa en hundvalp."