[bug #60077] Deterministic $@ for grouped targets patch

2021-06-21 Thread Todd Lowe
Follow-up Comment #7, bug #60077 (project make):

I wonder if &: makes sense as a pattern rule since regular pattern rules
already support multiple targets.  

Regardless, I have also tested your implicit test without the & and get the
same results:

$ cat ../makefile4
.SECONDEXPANSION:

all: world.z hello.x

%.x %.z: $$(info in prereqs @ = $$@, @< = $$(@<), @^ = $$(@^))
$(info in recipe @ = $@, @< = $(@<), @^ = $(@^))

$ ./make -f ../makefile4 hello.x
in prereqs @ = hello.x, @< = hello.x, @^ = hello.x
in recipe @ = hello.x, @< = hello.x, @^ = hello.x hello.z
make: 'hello.x' is up to date.

I also tried hello.z and $(@<) is only correct inside the recipe as well.
$ ./make -f ../makefile4 hello.z
in prereqs @ = hello.z, @< = hello.z, @^ = hello.z
in recipe @ = hello.z, @< = hello.x, @^ = hello.x hello.z
make: 'hello.z' is up to date.

The problem appears to be due to second expansion for pattern rules happening
quite some time before also_make is set in pattern_search().

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[bug #57898] Automatic variable for all targets on grouped target

2021-06-11 Thread Todd Lowe
Follow-up Comment #2, bug #57898 (project make):

bug #60077 provides a patch that adds $(@<) as the first target and $(@^) as
the list, along with D and F versions. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[bug #60077] Deterministic $@ for grouped targets patch

2021-06-11 Thread Todd Lowe
Follow-up Comment #6, bug #60077 (project make):

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.   

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[bug #60077] Deterministic $@ for grouped targets patch

2021-05-13 Thread Todd Lowe
Follow-up Comment #4, bug #60077 (project make):

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.
$(@https://file.savannah.gnu.org/file/0001-SV60077-add-grouped-targets-automatic-variables.patch?file_id=51432>



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[bug #60077] Deterministic $@ for grouped targets patch

2021-05-11 Thread Todd Lowe
Follow-up Comment #3, bug #60077 (project make):

I have a patch that introduces $(@<) as the first target and $(@^) as the
list, along with D and F versions of them.

I have not yet added a full suite of tests, and $(@^) is currently in reverse
order due to it simply following the internal also_make linked list.

Would you like this partial patch? 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[bug #60077] Deterministic $@ for grouped targets patch

2021-03-08 Thread Todd Lowe
Follow-up Comment #2, bug #60077 (project make):

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.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[bug #60077] Deterministic $@ for grouped targets patch

2021-02-18 Thread Todd Lowe
URL:
  

 Summary: Deterministic $@ for grouped targets patch
 Project: make
Submitted by: toddlowe
Submitted on: Thu 18 Feb 2021 06:42:02 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.3
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

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.




___

File Attachments:


---
Date: Thu 18 Feb 2021 06:42:02 PM UTC  Name:
0001-Make-always-return-the-1st-target-for-grouped-target.patch  Size: 4KiB  
By: toddlowe



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/