Re: GNU make suggestion: did the dependency really change?

[Paul D. Smith]

%% Henning Makholm <address@hidden> writes:

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

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

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

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

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

One way is to build that into your process, rather than trying to change
GNU make.

If a file does not change (that is, it's timestamp doesn't change), then
make will assume you didn't change it and it won't consider it updated,
and nothing it depends on will need to be rebuilt.

So, either change your build rule to grok this; maybe:

  %.ui : %.sig
            @[ -f $@ ] && mv $@ address@hidden
            mosmlc -c $<
            @cmp -s $@ address@hidden && mv address@hidden $@

Or, you could modify the mosmlc tool itself (if it's a local tool) to do
a similar thing.

It's true that this doesn't update the timestamps of the "unchanged"
files, so that this step will be repeated in the future.  However,
modifying timestamps is a very risky business.


Anyway, the problem you are encountering is just one special case of a
more fundamental problem, and I don't think it's a good idea to add in
code to manage that special case.  Instead, the fundamental problem
should be addressed: the problem I'm thinking of is the stateless nature
of make.  Make needs the ability to remember state from previous builds
in order to solve a whole class of problems, of which, as I say, this is
only one instance.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist