[bug #62706] Restrict second expansion to targets which are being built.

2022-07-30 Thread Paul D. Smith
Update of bug #62706 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM

___

Follow-up Comment #6:

Applied these changes; Thanks!


___

Reply to this item at:

  

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




[bug #62706] Restrict second expansion to targets which are being built.

2022-07-23 Thread Dmitry Goncharov
Follow-up Comment #5, bug #62706 (project make):

sv62706_fix2.diff takes care of secondary expanding a prerequisite marked as
intermediate by .SECONDARY or .INTERMEDIATE when an explicit or static pattern
rule builds the prerequisite.
sv62706_test2.diff adds related tests.


___

Reply to this item at:

  

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




[bug #62706] Restrict second expansion to targets which are being built.

2022-07-23 Thread Dmitry Goncharov
Additional Item Attachment, bug #62706 (project make):

File name: sv62706_fix2.diff  Size:5 KB


File name: sv62706_test2.diff Size:15 KB




___

Reply to this item at:

  

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




[bug #62706] Restrict second expansion to targets which are being built.

2022-07-09 Thread Paul D. Smith
Follow-up Comment #4, bug #62706 (project make):

Since secondary expansion is not defined in POSIX it doesn't really matter
what POSIX says about this, IMO: we could easily define it either way.

However, I think this change is correct and the way I would expect things to
work, so it's a good one.


___

Reply to this item at:

  

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




[bug #62706] Restrict second expansion to targets which are being built.

2022-07-09 Thread Dmitry Goncharov
Follow-up Comment #3, bug #62706 (project make):

Another thought on point 2 above.
Posix contains the following requirement.

"The make utility shall treat all prerequisites as targets themselves and
recursively ensure that they are up-to-date, processing them in the order in
which they appear in the rule."

Should word "processing" here be interpreted as any activity, including
secondary expansion (which posix does not define), needed to bring a
prerequisite up to date?

Secondary expansion of implicit rules in gnu make already satisfied these
requirements. This patch makes explicit and static pattern rules to satisfy as
well.



___

Reply to this item at:

  

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




[bug #62706] Restrict second expansion to targets which are being built.

2022-07-05 Thread Dmitry Goncharov
Follow-up Comment #2, bug #62706 (project make):

This is a more detailed description of point 2 above (2. Causes all
prerequisites to be second expanded in the same order they are being built.)


$ cat makefile
.SECONDEXPANSION:
all: hello.tsk bye.tsk
hello.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
bye.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
$ # this is patched make
$ ~/src/make/l64/make
2nd expansion of prereqs of hello.tsk
hello.tsk
2nd expansion of prereqs of bye.tsk
bye.tsk
make: Nothing to be done for 'all'.
$ # this is make-4.3
$ make
2nd expansion of prereqs of bye.tsk
2nd expansion of prereqs of hello.tsk
hello.tsk
bye.tsk
make: Nothing to be done for `all'.
$


We can see that make-4.3 builds 'hello.tsk' before building
'bye.tsk'. The order of secondary expanding prerequisites is the
opposite, first the prerequisites of 'bye.tsk' are expanded, then the
prerequisites of 'hello.tsk'.

The proposed behavior is to secondary expand the prerequisites of
'hello.tsk", build 'hello.tsk', secondary expand the prerequisites of
'bye.tsk', build 'bye.tsk'.

If however the makefile is changed like

$ cat makefile
.SECONDEXPANSION:
all: $$(info 2nd expansion for all) hello.tsk bye.tsk; $(info $@)
hello.tsk: $$(info 1st 2nd expansion of prereqs of $$@) $$(info 2nd 2nd
expansion of prereqs of $$@); $(info $@)
bye.tsk: $$(info 1st 2nd expansion of prereqs of $$@) $$(info 2nd 2nd
expansion of prereqs of $$@); $(info $@)
$ ~/src/make/l64/make
2nd expansion for all
1st 2nd expansion of prereqs of hello.tsk
2nd 2nd expansion of prereqs of hello.tsk
hello.tsk
1st 2nd expansion of prereqs of bye.tsk
2nd 2nd expansion of prereqs of bye.tsk
bye.tsk
all
make: 'all' is up to date.
$ make
2nd expansion for all
1st 2nd expansion of prereqs of bye.tsk
2nd 2nd expansion of prereqs of bye.tsk
1st 2nd expansion of prereqs of hello.tsk
2nd 2nd expansion of prereqs of hello.tsk
hello.tsk
bye.tsk
all
make: `all' is up to date.
$


Then $$(info 2nd expansion for all) is secondary expanded
before the prerequisites of hello.tsk and bye.tsk are secondary
expanded. The patch keeps this aspect of behavior is intact.



___

Reply to this item at:

  

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




Re: [bug #62706] Restrict second expansion to targets which are being built.

2022-07-05 Thread Dmitry Goncharov
On Tue, Jul 5, 2022 at 12:34 PM Edward Welbourne  wrote:
> was thinking of the fact that, if you'd started with
>
> all: $$(info 2nd expansion for all) hello.tsk bye.tsk; echo built both
>
> then its info would appear first, although its rule would be run last.

That's correct. $$(info 2nd expansion for all) is secondary expanded
before the prerequisites of hello.tsk and bye.tsk are secondary
expanded.

> I suppose that's unchanged by this patch, though,

Not changed.
This conversation made me realize that the description in the ticker
is not adequate. i'm going to update it. Thanks.

regards, Dmitry



Re: [bug #62706] Restrict second expansion to targets which are being built.

2022-07-05 Thread Edward Welbourne
On Tue, Jul 5, 2022 at 5:19 AM Edward Welbourne  wrote:
>>  I would have expected the order to be the exact reverse of the
>> order of building:

Dmitry Goncharov (5 July 2022 14:29) replied:
> i guess, an example will make it more clear.
>
> $ cat makefile
> .SECONDEXPANSION:
> all: hello.tsk bye.tsk
> hello.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
> bye.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)

ah, right - between prerequisites at a given depth, second-expansion now
happens in the same order as execution of their rules, fair enough.  I
was thinking of the fact that, if you'd started with

all: $$(info 2nd expansion for all) hello.tsk bye.tsk; echo built both

then its info would appear first, although its rule would be run last.
I suppose that's unchanged by this patch, though,

Eddy.



Re: [bug #62706] Restrict second expansion to targets which are being built.

2022-07-05 Thread Dmitry Goncharov
On Tue, Jul 5, 2022 at 5:19 AM Edward Welbourne  wrote:
>  I would have expected the order to be the exact reverse of the
> order of building:

i guess, an example will make it more clear.

$ cat makefile
.SECONDEXPANSION:
all: hello.tsk bye.tsk
hello.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
bye.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
$ # this is patched make
$ ~/src/make/l64/make
2nd expansion of prereqs of hello.tsk
hello.tsk
2nd expansion of prereqs of bye.tsk
bye.tsk
make: Nothing to be done for 'all'.
$ # this is make-4.3
$ make
2nd expansion of prereqs of bye.tsk
2nd expansion of prereqs of hello.tsk
hello.tsk
bye.tsk
make: Nothing to be done for `all'.
$


You can see that make-4.3 builds 'hello.tsk' before building
'bye.tsk'. The order of secondary expanding prerequisites is the
opposite, first the prerequisites of 'bye.tsk' are expanded, then the
prerequisites of 'hello.tsk'.

The proposed behavior is to secondary expand the prerequisites of
'hello.tsk", build 'hello.tsk', secondary expand the prerequisites of
'bye.tsk', build 'bye.tsk'.

regards, Dmitry



Re: [bug #62706] Restrict second expansion to targets which are being built.

2022-07-05 Thread Edward Welbourne
Dmitry Goncharov (5 July 2022 01:42) wrote (inter alia):
> 2. Causes all prerequisites to be second expanded in the same order
> they are being built.

Really ?  I would have expected the order to be the exact reverse of the
order of building:

src = main.c
hdr = lib.h
prog: $$(src); $(CC) -o $@ $<
main.c: $$(hdr)

surely has to evaluate $$(src) to discover that prog depends on main.c,
and only after it's discovered that will it evaluate $$(hdr); but if
there were a rule to make main.c from lib.h that rule would be evaluated
before the rule for prog.

> This fixes byte order dependent order of second expanding
> prerequisites. See sv 62175.

That, at least, should be the case either way.

Eddy.



[bug #62706] Restrict second expansion to targets which are being built.

2022-07-04 Thread Dmitry Goncharov
Follow-up Comment #1, bug #62706 (project make):

Second expand only the prerequisites of the targets being built.
Avoid second expanding the prerequisites of targets which are not being
built.

There are multiple benefits.

1. Avoids redundant work of second expanding prerequisites of the targets
which are not being built.

Example 1

.SECONDEXPANSION:
hello.tsk: $$(info 2nd exp for hello) $$(file https://savannah.gnu.org/bugs/?62706>

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




[bug #62706] Restrict second expansion to targets which are being built.

2022-07-04 Thread Dmitry Goncharov
Additional Item Attachment, bug #62706 (project make):

File name: sv62706_doc.diff   Size:4 KB


File name: sv62706_test.diff  Size:14 KB


File name: sv62706_fix.diff   Size:5 KB




___

Reply to this item at:

  

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




[bug #62706] Restrict second expansion to targets which are being built.

2022-07-04 Thread Dmitry Goncharov
URL:
  

 Summary: Restrict second expansion to targets which are being
built.
 Project: make
   Submitter: dgoncharov
   Submitted: Mon 04 Jul 2022 11:19:17 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Mon 04 Jul 2022 11:19:17 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  

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