Suggestion for a change in the out of date algorithm

[Ramón García]

Here is a couple of ideas for the out of date evaluation:

Instead of passing the list of targets and sources, pass a pair
(target, source) and evaluate the rule for each pair.

The rationale is that the user model is more restrictive, because we
assume that the out of date is always an and of out-of-date(target,
source_i) for each source. This restriction makes simpler for the
user. Consider writing a user defined rule for a pair, and writing it
for a list of sources. The list handling by hand will make it more
difficult for the end user to write such rules. I can't imagine a
single case where this flexibility is useful.

This method is somewhat slower. But not much slower, if the command
used in the .OUT_OF_DATE expression is implemented internally by make,
it would be the cost of a function call. Although shell commands will
be used, they will be used for evaluations of values used by the
out-of-date rather than the out-of-date itself.

Let us see the issue of cases where the out-of-date determination
should be different for different prerequisites of the same target

A.class: A.java B.class C.class

A.java does not depend on A.java and B.class in the same way. If
something in the implementation of A.java changes, it should be
recompiled, but the content of B.class and C.class is only relevant
for the interfaces that they export, rather than the implementations.

For handling cases like this, a new extension is proposed to make
expressions: a function to evaluate an expression in a different
context. If we call this function change-expression,
${change-expression target-name expression} will evaluate expression
in the context of target-name. Now, to solve cases like the previous
one, we declare some expression in a different way for different
prerequisites, and this expression is invoked from the .OUT_OF_DATE
rule using the change-expression macro.

For the previous example we would write the dependency of the
compilation of source A.java, which references classes B and C as:

# For each of its prerequisites, we evaluated changed in its context,
# and if it returns true, then A.class is recompiled


changed= .. some expression which determines if the current target has changed

A.class: .OUT_OF_DATE="${change-expression $< changed}"

A.class: A.java B.class_interface C.class_interface

and a pattern like

%.class_interface: changed= ... customized changed for .class_interface ...
%.class_interface: %.class

Now, how can we implemented these "changed" macros?

For handling persistent state of compilation rules, I suggest a
behavior close to the one proposed by Paul, but slightly more general.
I propose a macro

changed-value <name> expression

This macro returns true of the value of expression evaluated in the
previous make invocation is different from the current one. In
addition to returning true, the value obtained by this invocation is
stored. <name> is used for making it easier to manage persistent
stored values, so that different invocations of changed-value in
different places of the Makefile do not clash because of different
values of <name>.

For instance, changed could be implemented as:

%: changed=${changed-value md5 ${md5sum  address@hidden

%.class_interface: %.class
%.class_interface: changed=${changed-value md5_intf  ${shell
get-java-interface $< | md5sum}}

We use a hypotetical command get-java-interface that reads a .class
files and returns a file that contains interface definitions only.