Ben Boeckel wrote:
> Remember that tools like make *assume* that if a recipe is run, its
> specified outputs are out-of-date (there is no equivalent of ninja's
> `restat = 1`).

I can speak only for GNU's version of make, but this is not the case with
that implementation: if the target is not changed by the recipe, it won't
forcibly be considered out of date when used as a prerequisite of another
target.

> Better build tools that do hash comparison rather than
> mtime comparison may perform better. But BMI-writers should write
> outputs when they're told to do so. The *least* you can do to be
> reliable is to update the output mtime to the max(input_mtimes) because
> otherwise the rule will continue to be rerun because it is "out of
> date".

FI, the idiomatic way to handle this in GNU make is something along those
lines:

obj: bmi
        cp $< $@ # dummy compile

bmi: bmi.trigger
        cp mxx $_at_[hidden] # dummy precompile
        test -e $@ && cmp $_at_[hidden] $@ && rm $_at_[hidden] || mv -v $_at_[hidden] $@
        TZ=UTC touch -t 197001010000.01 $<

restarts:: mxx
        touch $@ bmi.trigger
-include restarts

mxx:
>$@ echo foo # dummy source