[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Mikhail]

Follow-up Comment #4, bug #62162 (project make):

Thanks, _$$(percent)_ trick makes the job done. 

However what is happening is still obscure. For example, here _patsubst_ does
everything correctly


lib1_SRCS := main.c try.c test.c
lib2_SRCS := lib.c api.c

.SECONDEXPANSION:
lib1 lib2: $$(patsubst %.c,%.o,$$($$@_SRCS))


and _lib1_  depends on main.o, try.o and test.o.

Reworking it in static pattern rule fashion results in prerequisites main.c,
try.c and test.c for _lib1_, i.e. patsubst does nothing.


lib1_SRCS := main.c try.c test.c
lib2_SRCS := lib.c api.c

.SECONDEXPANSION:
lib1 lib2: lib% : $$(patsubst %.c,%.o,$$(lib$$*_SRCS))


___

Reply to this item at:

  

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

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Mikhail]

Follow-up Comment #5, bug #62162 (project make):

Oh, I got it now, % expands as a stem of static pattern rule, and not being
used by patsubst. 

The issue is resolved. 

Thanks,
Mikhail

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62162>

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

Re: .SECONDARY unexpectedly affects rule invocation

[Mikhail]

I will reconsider usage of .SECONDARY in my applications and that should 
work.


Hope this thread highlighted a case worth considering for make devs.

Thanks,

Mikhail

On 05.10.2022 10:51, Dmitry Goncharov wrote:



On Tuesday, October 4, 2022, Mikhail Pomaznoy  wrote:

Martin's snippet indeed recapitulates the behavior resulted in my
initial report.

As for Dmitry's reply: I don't understand if /make/ does what's
expected or not.


Works as  documented. Even though I am not sure this particular case 
was envisioned.



 I believed that A.4 being a prereq of A.4.ind will always trigger
the latter being rebuilt if A.4 is newer.

It will, if A.4 is newer. In this case A.4 is not newer. A.4 is 
missing when make considers A.4.ind.


As a side note: I use make for running pipelines and add
.SECONDARY routinely because I don't want anything to be deleted
as temporary file


 Secondary without prerequisites is a bad idea.

Regards, Dmitry

-Mikhail

On 10/5/22 09:58, Dmitry Goncharov wrote:

On Tue, Oct 4, 2022 at 10:08 PM Martin Dorey
  <mailto:martin.do...@hitachivantara.com> 
 wrote:

  Isn't this slightly simplified example sufficient to demonstrate the same 
behavior...

A.4 is a preqreq to T.1 and also a prereq to A.4.ind.
A.4.ind is present and that's why make skips building secondary A.4
and keeps A.4.ind intact, while walking through A.4.ind prereqs.
T.1 is missing and this causes make to build A.4 in order to build
T.1, after A.4.ind is done with.

regards, Dmitry

[bug #35248] When running in debug-mode (-d), make reports a strange `multiple target patterns' error

[Mikhail T.]

URL:
  

 Summary: When running in debug-mode (-d), make reports a
strange `multiple target patterns' error
 Project: make
Submitted by: kot
Submitted on: Thu 05 Jan 2012 08:31:18 PM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.82
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Hello!

I'm working on a fairly convoluted set of makefiles and thought, using the -d
flag will help me.

Unfortunately, with this flag make began to through an error, that does not
appear, when make is run normally:

../../../coreconf/rules.mk:327: *** multiple target patterns.  Stop.

Having modified the source (read.c) as per the attached patch, I now get more
details:

*** FreeBSD8.2_OPT.OBJ/nssver.o
*** FreeBSD8.2_OPT.OBJ/utilwrap.o
*** FreeBSD8.2_OPT.OBJ/nss.def
*** ../certhigh/GNU
*** ../certhigh/Make
*** ../certhigh/3.82
*** ../certhigh/Built
*** ../certhigh/for
*** ../certhigh/amd64-portbld-freebsd8.2
*** ../certhigh/Copyright
*** ../certhigh/(C)
*** ../certhigh/2010
*** ../certhigh/Free
*** ../certhigh/Software
*** ../certhigh/Foundation,
*** ../certhigh/Inc.
*** ../certhigh/License
*** ../certhigh/GPLv3+
gmake[2]: Entering directory
`/home/ports/security/nss/work/nss-3.13.1/mozilla/security/nss/lib/nss'
../../../coreconf/rules.mk:327: *** FreeBSD8.2_OPT.OBJ/nssinit.o: multiple
target patterns.  Stop.

In other words, it seems, make somehow misinterprets the comments-section of a
Makefile... Using valgrind does not reveal any errors (except 4 "leaked"
bytes).

make-3.81 has a similar problem, but it manifests itself differently. Instead
of complaining about "multiple target patterns", make attempts to build bogus
targets like:

Live child 0x28337ca0 (../certhigh/2006) PID 92047 
Live child 0x28322b80 (../certhigh/(C)) PID 92046 
Live child 0x28337a90 (../certhigh/Copyright) PID 92045 
Live child 0x283378b0 (../certhigh/3.81) PID 92043 
Live child 0x283376d0 (../certhigh/Make) PID 92042 
Live child 0x28337220 (../certhigh/GNU) PID 92041 

This may very well be due to something being wrong with the makefiles, but
make's reaction should not differ depending on the debug flag...



___

File Attachments:


---
Date: Thu 05 Jan 2012 08:31:18 PM GMT  Name: patch-patterns-debug  Size: 889B 
 By: kot
Make the `multiple target patterns' error easier to debug


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #35248] When running in debug-mode (-d), make reports a strange `multiple target patterns' error

[Mikhail T.]

Follow-up Comment #2, bug #35248 (project make):

Yes, it certainly looks like make's own output is being parsed as a
makefile...

Line rules.mk:327 reads:

$(SHARED_LIBRARY): $(OBJS) $(RES) $(MAPFILE) $(SUB_SHLOBJS)

The project is Mozilla's NSS, BTW. Source downloaded from:

http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Target is not updated properly if intermediate prerequisite is in grouped targets rule with dry run, but ok in a real run

[Mikhail P]

Greetings!

I get unexpected behavior with the following toy makefile when *d_file* 
is newer than *a_file*


|a_file : b_file||
||    echo "making a_file from $<" > $@||
||
||b_file c_file &: d_file||
||    echo "making b_file from $<" > b_file||
||    echo "making c_file from $<" > c_file||
||
||d_file :||
||    echo "making d_file" > $@||
|
If I run make with this file I get the needed a_file and intermediate 
b_file, c_file and d_file which is good. If I touch *d_file* and run 
|make -n| I get


|echo "making b_file from d_file" > b_file||
||echo "making c_file from d_file" > c_file|

If I remove dry run switch than additionally the command

|echo "making a_file from $<" > $@|

is executed. Why dry run shows incorrect commands? Isn't it obvious in a 
dry run tha file a_file should also be updated?


Thanks,

-Mikhail

.SECONDARY unexpectedly affects rule invocation

[Mikhail Pomaznoy]

Greetings,

I have encountered weird behavior in make and tried to isolate it.  The 
software was built from source.


I have the following Makefile:

|RECIPE = echo "Making $@ from $^" > $@||
||T.1 : A.4 A.4.ind; $(RECIPE)||
||A.4 : A.3 A.3.ind ||
||    $(RECIPE)||
||A.2 :||
||    $(RECIPE)||
||A.3 : A.2||
||    $(RECIPE)||
||A.3.ind A.4.ind : %.ind : %||
||    $(RECIPE)||
||.SECONDARY:|

And the current directory contains///A.3.in//d///and /A.4.ind/ .

I want to make target /T.1//. /If I run

|make T.1|

Then the following commands are executed:

|echo "Making A.2 from " > A.2||
||echo "Making A.3 from A.2" > A.3||
||echo "Making A.4 from A.3 A.3.ind" > A.4||
||echo "Making T.1 from A.4 A.4.ind" > T.1|

I.e. /A.4.ind/ and /A.3.ind /are never updated, while /A.4/ was updated. 
It means the very last command will use invalid A.4.ind file. This is a 
bit unexpected to me already. Moreover, if I remove .SECONDARY,/A.4.ind/ 
or /A.3.ind/ ARE updated while preparing /T.1./


Could you please clarify or investigate ?

-Mikhail
//

Re: .SECONDARY unexpectedly affects rule invocation

[Mikhail Pomaznoy]

A further note: it's version 4.3 of make

On 10/4/22 14:57, Mikhail Pomaznoy wrote:


Greetings,

I have encountered weird behavior in make and tried to isolate it.  
The software was built from source.


I have the following Makefile:

|RECIPE = echo "Making $@ from $^" > $@||
||T.1 : A.4 A.4.ind; $(RECIPE)||
||A.4 : A.3 A.3.ind ||
||    $(RECIPE)||
||A.2 :||
||    $(RECIPE)||
||A.3 : A.2||
||    $(RECIPE)||
||A.3.ind A.4.ind : %.ind : %||
||    $(RECIPE)||
||.SECONDARY:|

And the current directory contains///A.3.in//d///and /A.4.ind/ .

I want to make target /T.1//. /If I run

|make T.1|

Then the following commands are executed:

|echo "Making A.2 from " > A.2||
||echo "Making A.3 from A.2" > A.3||
||echo "Making A.4 from A.3 A.3.ind" > A.4||
||echo "Making T.1 from A.4 A.4.ind" > T.1|

I.e. /A.4.ind/ and /A.3.ind /are never updated, while /A.4/ was 
updated. It means the very last command will use invalid A.4.ind file. 
This is a bit unexpected to me already. Moreover, if I remove 
.SECONDARY,/A.4.ind/ or /A.3.ind/ ARE updated while preparing /T.1./


Could you please clarify or investigate ?

-Mikhail

Re: .SECONDARY unexpectedly affects rule invocation

[Mikhail Pomaznoy]

Martin's snippet indeed recapitulates the behavior resulted in my 
initial report.


As for Dmitry's reply: I don't understand if /make/ does what's expected 
or not. I believed that A.4 being a prereq of A.4.ind will always 
trigger the latter being rebuilt if A.4 is newer.


As a side note: I use make for running pipelines and add .SECONDARY 
routinely because I don't want anything to be deleted as temporary file


-Mikhail

On 10/5/22 09:58, Dmitry Goncharov wrote:

On Tue, Oct 4, 2022 at 10:08 PM Martin Dorey
  wrote:

  Isn't this slightly simplified example sufficient to demonstrate the same 
behavior...

A.4 is a preqreq to T.1 and also a prereq to A.4.ind.
A.4.ind is present and that's why make skips building secondary A.4
and keeps A.4.ind intact, while walking through A.4.ind prereqs.
T.1 is missing and this causes make to build A.4 in order to build
T.1, after A.4.ind is done with.

regards, Dmitry