Thank you for your feedback Dmitry. 

I'm going to start sounding like a broken record here, but again I'm not sure when I will be able to look at this.  If I get a chance before anyone else picks it up, I will debug using your test case and post an update.

I've had a bit more time and am uploading a patch with my latest version.  Unfortunately I'm not sure when I'll be able to test it in production, but I wanted to share sooner than later.

This one adds new automatic variables for grouped targets, both explicit and pattern along with new grouped targets and variables test cases.

$(@<) Is the first specified target
$(@^) Is the list of targets in the order specified in the goal definition.
$(@<F), $(@<D), $(@^F), and $(@^D) are also implemented.

My implementation makes two changes to how the also_makes list is stored in order to facilitate the automatic variables.
1 - The stored order now matches the order specified in the rule.
2 - also_makes for pattern rules didn't include the executing target.  This is different than explicit grouped targets where all targets are included in the list.  I have changed this so all targets are always stored in also_makes, but I am concerned there may be side effects of this change.  I do not use pattern rules enough to know, but it does pass the test suite.



(file #51432)

I admit I wasn't too thrilled about making $@ behave differently between explicit and pattern rules, but I definitely did not want to change the long standing pattern rule behaviour and didn't find the grouped-target $@ useful.  I had proposed $! for instigating target, but I can see that the inconsistency in that would be worse than the solution.

I'm not sure why I didn't like the idea of $(firstword $&), but likely because I was too focused on $@ not behaving the way it did with my pseudo grouped-targets by macro :-)

I had not thought about $(@^) and $(@<), but I like the consistency they have with the existing variables.

I wrote my patch last fall and other priorities have delayed our move to 4.3. If I get back to it before someone else, I will implement these and provide a new patch.

My team currently uses a macro that expands to multiple rules as a way to simulate a rule with multiple targets.  I would like to use grouped-targets instead, but like others, have discovered that $@ referring to the target that triggered execution rather than a specific target from the list makes it difficult to use.

I have had a look at
[bug #57898] Automatic variable for all targets on grouped target
and
[bug #58845] In would be nice to have "$&" expand to all targets in a grouped target
But they refer to a way to get all targets rather than a deterministic way to always get a “primary target”.

For my use case, I would like $@ to always expand to a specific target from the grouped list, similar to how $< is always the first prereq.  I’m not a fan of non-backwards compatible changes, but due to the way grouped-targets works,  I think this change makes $@ more useful and allows it’s behaviour to be more consistent between regular recipes and grouped-target recipes.

I’ve attached a patch that causes $@ for grouped-targets to always be the first target from the list plus changes to the test suite for the new behaviour.

Matching the prereq behaviour of having variables for first, trigger, and all seems cleaner than requiring recipes to extract a target from the entire list so I am also considered adding $& for all a new $! to represent the triggering target.

Since my current need is only for $@ to consistency return a specific target, that is what I have implemented and want to share.   

In order to not force this behaviour change on multi-target pattern rules, I ended up adding a “grouped_target” file flag and only apply my change if it is set.  I didn’t want to add an extra flag, but other attempts at excluding pattern-rules quickly became messy.