%% Henning Makholm <[EMAIL PROTECTED]> 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 $@ $@.old
mosmlc -c $<
@cmp -s $@ $@.old && mv $@.old $@
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 <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
