Re: Re%3A%5BPATCH%5D%20document%20the%20use%20of%20stamps%20in%20gcc%2FMakefile.in

[Rafael EspÃndola <rafael dot espindola at gmail dot com>]

Sorry for the huge delay.

> >> If you want to elaborate it further, you may want to mention that in
> >> some cases people will remove tree-check.h and then be confused
> >> because it is not rebuilt.  Instead of `@true', one may (should?) use
> >> `@if [ ! -f $@ ]; then rm -f s-check; $(MAKE) s-check; fi' or so.
>
> > This will update s-check in a rule that does't have s-check in the
> > left hand side.
>
> Just like the s-check rule wil update tree-check.h even though it's
> not on the left hand side.

and that is why we need the

tree-check.h: s-check; @true

in the first place. But we can't use the same method again because it
would create a loop.

> Point is, s-check *must* not be used in any dependency, and the only
> place where we ever run this target explicitly is as a dep of the file
> that is controlled by the stamp, or in the command thereof.  As long
> as the stamp file controls only this one file, I don't see how it
> could ever cause any problems.

I agree. The problem is that some stamps are used in more targets. For
example, s-gtype.

> If the stamp controls multiple files,
> then yes, there is potential for trouble in parallel builds.
>
> > Maybe we could restart make by touching an empty include. Something
> > like the exemple:
>
> I'm not sure how this would help.  If anything, it would cause a to be
> needlessly updated for any make target, since then the construction of
> the Makefile graph would depend on it.
>
This is how the automatic dependency computation with the ".d" files
work. It is a way of informing GCC that we have messed with its
dependency graph and that it should reconsider. In this case, the next
time that it starts, the stamp will no longer exist and make will work
correctly.

I am not used to make's internals, but I am starting to think that it
might be a good idea to implement a hash based change decisions in GNU
make (similar to scons) :-(

Rafael