Do not treat primary ad hoc group member as group for variable lookupadhoc-vars

Note that we started with this semantics but it was changed in a commit on
2021-09-16 for reasons not entirely unclear but most likely due to target-
specific variables specified for the group not being set on all the members.
Which we have now addressed (see the previous commit).

Note also that this new (old) semantics is not without its own drawbacks.
Specifically, there is a bit of waste when the target-specific variable is
really only meant for the recipe and thus setting it on all the members is
unnecessary. For example:

<{hxx ixx cxx}{options}>: cli{options}
{
  options = ...
}
{{
   # Use options.
}}

But this feels like a quality of implementation rather than conceptual
issue. For example, we could likely one day address it by synthesizing a
separate group target for ad hoc groups.

1 files changed, 6 insertions, 4 deletions

diff --git a/libbuild2/algorithm.cxx b/libbuild2/algorithm.cxx
index d69ff95..76f7c4c 100644
--- a/libbuild2/algorithm.cxx
+++ b/libbuild2/algorithm.cxx
@@ -1853,6 +1853,7 @@ namespace build2
   {
     using mode = backlink_mode;
 
+    context& ctx (t.ctx);
     const scope& s (t.base_scope ());
 
     backlinks bls;
@@ -1895,11 +1896,12 @@ namespace build2
         // Note that we want to avoid group or tt/patter-spec lookup. And
         // since this is an ad hoc member (which means it was either declared
         // in the buildfile or added by the rule), we assume that the value,
-        // if any, will be set as a rule-specific variable (since setting it
-        // as a target-specific wouldn't be MT-safe). @@ Don't think this
-        // applies to declared ad hoc members.
+        // if any, will be set as a target or rule-specific variable.
         //
-        lookup l (mt->state[a].vars[t.ctx.var_backlink]);
+        lookup l (mt->state[a].vars[ctx.var_backlink]);
+
+        if (!l)
+          l = mt->vars[ctx.var_backlink];
 
         optional<mode> bm (l ? backlink_test (*mt, l) : m);