Add notion of match options

Now, when matching a rule, the caller may request a subset of the full
functionality of performing an operation on a target. This is achieved
with match options.

1 files changed, 9 insertions, 2 deletions

diff --git a/libbuild2/rule.hxx b/libbuild2/rule.hxx
index dea9c9a..acd22fe 100644
--- a/libbuild2/rule.hxx
+++ b/libbuild2/rule.hxx
@@ -34,6 +34,10 @@ namespace build2
   // implementations. It is also a way for us to later pass more information
   // without breaking source compatibility.
   //
+  // A rule may support match options and if such a rule is rematched with
+  // different options, then reapply() is called. See
+  // match_extra::{cur,new}_options for background and details.
+  //
   struct match_extra;
 
   class LIBBUILD2_SYMEXPORT rule
@@ -45,6 +49,9 @@ namespace build2
     virtual recipe
     apply (action, target&, match_extra&) const = 0;
 
+    virtual void
+    reapply (action, target&, match_extra&) const;
+
     rule () = default;
 
     virtual
@@ -265,8 +272,8 @@ namespace build2
     // is a pattern and returns true otherwise.
     //
     // Note also that in case of a member of a group-based target, match() is
-    // called on the group while apply() on the member (see match_rule() in
-    // algorithms.cxx for details). This means that match() may be called
+    // called on the group while apply() on the member (see match_rule_impl()
+    // in algorithms.cxx for details). This means that match() may be called
     // without having the target locked and as a result match() should (unless
     // known to only match a non-group) treat the target as const and only
     // rely on immutable information (type, name, etc) since the group could