Re: Idea: Add .COMMANDCHANGE and .CACHE

[David A. Wheeler]

On Mon, 10 Jun 2019 12:10:26 -0800, Britton Kerin <address@hidden> wrote:
> The trickery required is not too fancy:
> 
>      foo.o: foo.c Makefile
>              ...
> or
> 
>      foo.o: foo.c $(PARANOID_REBUILD)
>              ...
> 
> Then use when desired:
>      (export PARANOID_REBUILD=Makefile && Make)

No.

That's not at *ALL* the same thing.  With those uses, *all* rules
are rerun if *ANY* change happens in the Makefile, even if almost
all the rules and parameters do not change at all.
Since the whole point of make is to "only run what's needed",
that doesn't resolve the problem at all.

In contrast, ".COMMANDCHANGE" would only run a rule
if that PARTICULAR rule changed (once expanded) in the Makefile.
In many cases that would skip much of the work.
Which is the point.


> > In addition, sometimes recipes take a while, and it'd be nice to be able to
> > cache old results. If we have to store state anyway,
> > we may as well support caching previous results.
> 
> This is IMO an entirely new and mostly orthogonal project from Make,
> and there is
> already ccache (and presumably similar things for other langs).

Caching is new functionality, that's why it's a proposal :-).

But I don't think it's orthogonal.

(1) The point of make is to "do only the tasks that are needed";
  Caching previous results seems like a very reasonable part
  of the definition of doing only what's needed.
(2) Not all languages have a ccache-like functionality.
(3) make is widely used for tasks other than compiling source code
   (e.g., to implement data processing pipelines), which again
   means that they don't have a ccache-like ability
(4) Implementing caches in make solves the problem *once* for
  *all* uses of make, instead of requiring every user to recreate it.
(5) Make is in a very good spot to know what's going to be done.
(6) The implementation will be trivial, probably ~20 lines of code
  plus the hashing function.  While the functionality will be significant
  for *users*, there should be practically no maintenance burden
  due to its small size.

--- David A. Wheeler