[bug #63098] make-4.3.90 regression of unexpected dependencies in pattern rules with multiple targets

[Paul D. Smith]

Update of bug #63098 (project make):

  Status:   Not A Bug => Fixed  
 Assigned to:None => psmith 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #6:

I pushed a change that brings back the old behavior, for this release, and
generates a warning when it is detected.

In the next release, once people have a chance to fix their makefiles, we will
switch to the new behavior.

We will track that via bug #12078


___

Reply to this item at:

  

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

[bug #63098] make-4.3.90 regression of unexpected dependencies in pattern rules with multiple targets

[Paul D. Smith]

Update of bug #63098 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #5:

I'm going to close this for now.  We will see how things go throughout the
rest of the testing to see if this is a serious problem or not.

I verified that the docs don't make any explicit guarantees about this, and so
I updated them to be more clear about the behavior and I also added a note to
the NEWS about this change.


___

Reply to this item at:

  

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

[bug #63098] make-4.3.90 regression of unexpected dependencies in pattern rules with multiple targets

[Paul D. Smith]

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

Yes, I saw that behavior when I looked at the repo.  I agree it's difficult to
see how to map that onto make's current behavior.  I'll take a look through
the manual to see if that change (which was somewhat last-minute) might be
going against some previously-guaranteed behavior.

In general it's very hard to express a situation like "the set of output files
being generated depends on the contents of the input file" in make; it wasn't
really designed that way (as an extreme example this is why you can't use make
with Java very well).

If only some of the msg files generate .cxx files then my last option below,
splitting into two different pattern rules, would probably work best.

Another option of course is (since they already require GNU make) to simply
use a $(shell ...) function to grep out which msg files contain the special
marking, and use a static pattern rule to handle those differently with a
different set of outputs.  Unfortunately without GNU make 4.3's grouped
targets it's tricky to get this right; if you want to run with older versions
of GNU make this won't work well.


___

Reply to this item at:

  

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

[bug #63098] make-4.3.90 regression of unexpected dependencies in pattern rules with multiple targets

[Sergei Trofimovich]

Follow-up Comment #3, bug #63098 (project make):

Aha, behavior change makes sense. Let's close it as intended then.

Looks like opensp's case is even more nuanced. `%.h %.cxx %.rc: %.msg`
produces `.cxx` files only for a subset of `.msg` files: `.cxx` generation
happens only where file contents has `!cxx` marking. Otherwise only `.h` and
`.rc` are produced. That explains why tarballs don't contain some of `.cxx`
files and cause the rules to attempt to regenerate them at each `make`
invocation.

I filed https://sourceforge.net/p/openjade/bugs/151/ against opensp upstream.
Looks like last activity was in 2007, might take a long while to get fixed.
I'll attach the path there if I manage to get something working.

Thank you!


___

Reply to this item at:

  

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

[bug #63098] make-4.3.90 regression of unexpected dependencies in pattern rules with multiple targets

[Paul D. Smith]

Update of bug #63098 (project make):

   Component Version:None => SCM
Operating System:None => Any

___

Follow-up Comment #2:

This change was made to fix bug #12078

The problem with the old behavior can be seen in examples provided for bug
#62809 (for grouped targets not pattern rules but the result is the same)
where running "make" can cause things to become out of date, that will not
rebuild until you run "make" again.  Which is not good.

I understand the behavior that used to be available, and I'm not sure how to
recover it.  Basically the rule (now) is that if any target in a multi-target
rule doesn't exist (or is out of date), and any target of a multi-target rule
(and this doesn't have to be the SAME target) is needed as part of the build,
then the recipe will be run and all the targets will be considered to have
been updated.

The simplest answer is to ship the .cxx files that are generated as well as
the .h and .rc files.

The second simplest answer is to remove the %.cxx from the pattern rule, if
it's really true that nothing else in the makefiles actually depends on these
files anyway.

A different answer would be to split the make rules; something like this might
work:

%.h %.rc: %.msg
[ ! -f $(top_srcdir)/msggen.pl ] || $(PERL) -w $(top_srcdir)/msggen.pl
$(MSGGENFLAGS) $<

%.cxx : %.rc
: built by perl from $*.msg


I'm not sure this is completely correct without knowing more about the build
environment.  In this example, if nothing depends on the .cxx file and it's
missing, then it won't force the Perl script to run.


___

Reply to this item at:

  

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

[bug #63098] make-4.3.90 regression of unexpected dependencies in pattern rules with multiple targets

[Dmitry Goncharov]

Follow-up Comment #1, bug #63098 (project make):

This is not a regression. This is the intended behavior. Make runs the rule to
build foo.c. See fabb03eac412b5ea19f1a97be31dc8c6fa7fc047


___

Reply to this item at:

  

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

[bug #63098] make-4.3.90 regression of unexpected dependencies in pattern rules with multiple targets

[Sergei Trofimovich]

URL:
  

 Summary: make-4.3.90 regression of unexpected dependencies in
pattern rules with multiple targets
 Project: make
   Submitter: slyfox
   Submitted: Fri 23 Sep 2022 07:05:25 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Fri 23 Sep 2022 07:05:25 PM UTC By: Sergei Trofimovich 
Initially noticed the problem in OpenSP-1.5.2 build failure. Here is a
minimised example:


# cat Makefile
all: foo.a foo.b

%.a %.b %.c: %.d
touch $*.a
touch $*.b
touch $*.c


To trigger it we need to have up-to-date foo.d, foo.a and foo.b:


$ touch foo.d; touch foo.a; touch foo.b

# good make-4.3:
$ make-4.3
make: Nothing to be done for 'all'.

# problematic make-4.3.90:
$ make-4.3.90
touch foo.a
touch foo.b
touch foo.c


Note how new make version decided it needs to do extra work.

Looks like a bug.

A bit of background on original bug context (in case I extracted it
incorrectly):

OpenSP-1.5.2 uses similar pattern in
https://sourceforge.net/p/openjade/code/HEAD/tree/trunk/sp/lib/Makefile.am


# ...
%.h %.cxx %.rc: %.msg
[ ! -f $(top_srcdir)/msggen.pl ] || $(PERL) -w $(top_srcdir)/msggen.pl
$(MSGGENFLAGS) $<


OpenSP's release tarball ships only .h and .rc files (but not .cxx):
lib/WinInetStorageMessages.h lib/WinInetStorageMessages.msg
lib/WinInetStorageMessages.rc. It looks like nothing requires .cxx files in
that directory.

I only noticed the failure because my sandbox environment did not have perl
and caused build failure of make upgrade to 4.3.90.







___

Reply to this item at:

  

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