%% Nathanael Nerode <[EMAIL PROTECTED]> writes:
nn> This is a very simple request, which would have an incredible
nn> amount of value.
It's actually not clear that it would be as simple to implement as you
say. Unfortunately internally GNU make doesn't have a simple "call a
function and if it returns true the file is up to date, if it returns
false it needs to be rebuilt". The code is not architected that way.
nn> The feature is totally arbitrary methods of testing whether a
nn> target needs to be rebuilt.
The goal for the next feature release of GNU make is to allow for an
embedded scripting language (Guile). At that point you will be able to
do all sorts of interesting things, I expect.
nn> If it needs to be rebuilt, its prerequisites need to be checked to
nn> see if they need to be rebuilt. If it doesn't, they aren't
nn> checked, at all.
Hm. That's not how make works. Make _ALWAYS_ builds the prerequisites
first, _THEN_ decides whether the target needs to be rebuilt. Any
attempt to replace the default testing _must_, at least by default,
follow the traditional behavior in this matter. For the large majority
of situations you can't even determine whether or not a target can be
rebuilt unless you know whether its prerequisites will be/have been.
You are really asking for two features here, which must be treated
separately: a new "pre-test" which is invoked when make is walking
_down_ the dependency graph, plus a way to replace the current test,
which is performed when make is walking back up the dependency graph.
Actually, you can already do the latter without too much extra overhead,
like this... translate your example:
foo: bar baz ? is-foo-up-to-date
commands
into this:
foo: foo.up-to-date
commands
foo.up-to-date: bar baz
if is-foo-up-to-date; then \
touch $@; \
else
: make $@ to be very old; \
fi
In this situation foo will only be rebuilt if is-foo-up-to-date said it
should be.
The former (testing on the way down the graph) is not possible
currently, as far as I can tell.
nn> It would be a nice piece of icing on the cake if make also passed
nn> an environment variable into is-foo-up-to-date which contained the
nn> information as to whether the prereqs were up to date, but this is
nn> a further refinement and not really very important.
I would assume that the alternate test would be invoked within the scope
of the full automatic variable settings, so things like $@, $^, $?,
etc. would be available to it.
nn> Note that .PHONY and order-only dependencies can both be expressed
nn> as special cases of this.
Given the idea that the test should be done before the prerequisites
were built I don't see how order-only prerequisites could be handled,
unless you mean you could invoke a recursive make from within the test
script.
If the prerequisites were done first, then the test, then sure, the test
could ignore the TLM on some of the prerequisites.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
