Feature request: User-specified update tests

[Nathanael Nerode]

This is a very simple request, which would have an incredible amount of 
value.  It would take me a long time to code it myself, just due to the time 
needed to learn the internals of GNU make.  I will if I have to, but I 
suspect it would be a very quick piece of coding for someone who already 
knows how GNU make is organized internally.

The feature is totally arbitrary methods of testing whether a target needs to 
be rebuilt.  This can be specified with the syntax of your choice; my 
preference is

foo: bar baz ? is-foo-up-to-date
        commands

Of course that would be bad if ? is a common file name. :-)  But I really 
don't care about the syntax; if the syntax was
.HAS_UNUSUAL_UP_TO_DATE_CHECK: foo
.UP_TO_DATE_CHECK_FOR_foo:
        is_foo_up_to_date

I'd be just as happy, really.

"is-foo-up-to-date" would be a shell command which returned exit status 0 if 
the file was up to date, and exit status 1 if it needed to be rebuilt.

If it needs to be rebuilt, its prerequisites need to be checked to see if 
they need to be rebuilt.  If it doesn't, they aren't checked, at all.

It would be a nice piece of icing on the cake if make also passed an 
environment variable into is-foo-up-to-date which contained the information 
as to whether the prereqs were up to date, but this is a further refinement 
and not really very important.

It could also be specified that we want a whole bunch of targets to be tested 
in a particular way, but I think this is another unimportant refinement; 
simply evaluating the standard MAKE macros within the text of 
is_foo_up_to_date, as they are evaluated within commands, would in fact 
enable this.

My point is that I want a way to specify, for a particular target, that it 
has an unusual way of determining whether it's up to date.  I have 
encountered lots of subtle issues when using make, *all* of which could be 
dealt with using this *one* extension, and different plugins for the command. 
Speed isn't an issue, for two reasons: first, this is generally only desired 
for one or two targets in a large Makefile; second, the alternative 
workarounds being used, in all cases, are either much much slower than the 
overhead of calling out to a shell to determine up-to-dateness, or don't 
actually work correctly.

Note that .PHONY and order-only dependencies can both be expressed as special 
cases of this.  Those special cases probably deserve the speed of being built 
in, but it does illustrate how useful a general facility this would be.

Any takers?  Anyone who sees a reason why this would actually be really hard 
to do?

--Nathanael Nerode
address@hidden