Add update operation-specific variable with unmatch|match additional values

Note that the unmatch (match but do not update) and match (update during
match) values are only supported by certain rules (and potentially only for
certain prerequisite types).

Additionally:

- All operation-specific variables are now checked for false as an override
  for the prerequisite-specific include value. In particular, this can now be
  used to disable a prerequisite for update, for example:

  ./: exe{test}: update = false

- The cc::link_rule now supports the update=match value for headers and ad hoc
  prerequisites. In particular, this can be used to make sure all the library
  headers are updated before matching any of its (or dependent's) object
  files.

1 files changed, 28 insertions, 8 deletions

diff --git a/libbuild2/context.hxx b/libbuild2/context.hxx
index 3563c16..20098dc 100644
--- a/libbuild2/context.hxx
+++ b/libbuild2/context.hxx
@@ -283,6 +283,8 @@ namespace build2
     const operation_info* current_inner_oif;
     const operation_info* current_outer_oif;
 
+    const variable* current_ovar; // Current (outer) operation variable.
+
     action
     current_action () const
     {
@@ -428,6 +430,19 @@ namespace build2
     //
     const variable* var_extension;
 
+    // This variable can only be specified as prerequisite-specific (see the
+    // `include` variable for details).
+    //
+    // [string] prerequisite visibility
+    //
+    // Valid values are `true` and `false`. Additionally, some rules (and
+    // potentially only for certain types of prerequisites) may support the
+    // `unmatch` (match but do not update, if possible) and `match` (update
+    // during match) values. Note that if unmatch is impossible, then the
+    // prerequisite is treated as ad hoc.
+    //
+    const variable* var_update;
+
     // Note that this variable can also be specified as prerequisite-specific
     // (see the `include` variable for details).
     //
@@ -473,14 +488,19 @@ namespace build2
     // Sometimes it may be desirable to apply exclusions only to specific
     // operations. The initial idea was to extend this value to allow
     // specifying the operation (e.g., clean@false). However, later we
-    // realized that we could reuse the "operation variables" (clean, install,
-    // test) with a more natural-looking result. Note that currently we only
-    // recognize the built-in clean variable (for other variables we will need
-    // some kind of registration in an operation-to-variable map, probably in
-    // root scope). See also install::file_rule::filter().
-    //
-    // To query this value in rule implementations use the include() helpers
-    // from <libbuild2/prerequisites.hxx>.
+    // realized that we could reuse the "operation-specific variables"
+    // (update, clean, install, test; see context::current_ovar) with a more
+    // natural-looking and composable result. Plus, this allows for
+    // operation-specific "modifiers", for example, "unmatch" and "update
+    // during match" logic for update (see var_update for details) or
+    // requiring explicit install=true to install exe{} prerequisites (see
+    // install::file_rule::filter()).
+    //
+    // To query this value and its operation-specific override if any, the
+    // rule implementations use the include() helper.
+    //
+    // Note that there are also related (but quite different) for_<operation>
+    // variables for operations that act as outer (e.g., test, install).
     //
     // [string] prereq visibility
     //