Do not treat primary ad hoc group member as group for variable lookup

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, 18 insertions, 0 deletions

diff --git a/libbuild2/target.cxx b/libbuild2/target.cxx
index 78bc5ac..41a3273 100644
--- a/libbuild2/target.cxx
+++ b/libbuild2/target.cxx
@@ -158,6 +158,11 @@ namespace build2
     {
       ++r.second;
 
+      // While we went back to not treating the first member as a group for
+      // variable lookup, let's keep this logic in case one day we end up with
+      // a separate ad hoc group target.
+      //
+#if 0
       // In case of an ad hoc group, we may have to look in two groups.
       //
       if ((g1 = group) != nullptr)
@@ -175,6 +180,19 @@ namespace build2
           }
         }
       }
+#else
+      // Skip looking up in the ad hoc group, which is semantically the
+      // first/primary member.
+      //
+      if ((g1 = group == nullptr
+           ? nullptr
+           : group->adhoc_group () ? group->group : group))
+      {
+        auto p (g1->vars.lookup (var));
+        if (p.first != nullptr)
+          r.first = lookup_type (*p.first, p.second, g1->vars);
+      }
+#endif
     }
 
     // Delegate to scope's lookup_original().