Feedback about persistence mechanism.

[Ramón García]

Hello,

There is an issue not yet resolved with persistent variables, and I
would like to get your opinions.

The current mechanism is based on a builtin function called
changed-value. The function is invoked as

${changed-value name,expression}

and returns true if the last time this function is called for the same
value of name, expression had the same value as in the present call.
As a side effect, the value of expression is recorded, for the next
call.

The intended usage is:

b: changed=${changed-value b.sum ${shell checksum b}}

the expression $changed may be used by the .OUT_OF_DATE expression
which selects when a target is out of date.

The issue is, this expression may be evaluated several times. For
instance different targets which take b as prerequisite. The first
call would be OK, but the second would return that b is up to date
when it is not.

There are two possible solutions, and I want to know which one do you prefer.

1) the function changed-value caches calls, so that if it is called
twice for the same value of name, it returns the value of the first
call.
Pros: changed-value behaves the way the user expects.
Cons: it introduces a hardwired behaviour which might not be what the
user wants, though it is the best one for this case.
        it is inefficient: the checksum would be still evaluated
twice (the second time would be discarded) because of the order of
variable expansions in make, the ${shell checksum src} would be
evaluated the second time.
            Fixing this inefficiency is not easy, because it would
require the expression parser notice that a substitution includes a
function that caches depending of its first argument, so the second
needs not be expanded, ...

2) A new keyword is introduced which causes make to remember variable
value from one invocation to the next.

cached changed=${changed-value b.sum ${shell checksum b}}
means, in the first invocation the value is recorded, the second and
others it is just remembered.

You may ask: why not use :=  ?

It does not work. Consider that one would naturally write a pattern
for defining changed:
%: changed:=${changed-value address@hidden ${sum checksum address@hidden

This cannot work, because the definition of changed is shared by all
the targets that meet the pattern, and all would share the same value
of changed. changed would be evaluated when the definition is parsed,
and $@ is void at that time, because the pattern is not considered in
the context of a concrete rule at that time.

Note that, to take this case into account

%: cached variable=expression

must cache in a different location for every different context where
variable is used and can return something different.

Pros: it is more flexible. users can use the new attribute for whatever it fits.
Cons: the function changed-value behaves in an surprising way, because
it is invoked
        several times it returns always false except (perhaps) in the
first. Good documentation
        including cooked examples is necessary.

Personally, I prefer the second choice because it is simpler, and
simple is always implicitly less surprising.