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
[EMAIL PROTECTED]
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
