bugmake - Bugs: bug #63098, make-4.3.90 regression of...

 
 

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

Submitter:  Sergei Trofimovich <slyfox>
Submitted:  Fri 23 Sep 2022 07:05:25 PM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.4 Operating System:  Any
Fixed Release:  4.4 Triage Status:  Medium Effort
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 02 Oct 2022 06:27:40 PM UTC, 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

Paul D. Smith <psmith>
Group administrator
Sun 25 Sep 2022 10:49:47 PM UTC, 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.

Paul D. Smith <psmith>
Group administrator
Fri 23 Sep 2022 10:00:01 PM UTC, comment #4: 

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.

Paul D. Smith <psmith>
Group administrator
Fri 23 Sep 2022 09:22:20 PM UTC, comment #3: 

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!

Sergei Trofimovich <slyfox>
Fri 23 Sep 2022 08:41:23 PM UTC, 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.

Paul D. Smith <psmith>
Group administrator
Fri 23 Sep 2022 08:18:41 PM UTC, comment #1: 

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

Dmitry Goncharov <dgoncharov>
Fri 23 Sep 2022 07:05:25 PM UTC, original submission:  

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.

Sergei Trofimovich <slyfox>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by dgoncharov (Posted a comment)
  • -email is unavailable- added by slyfox (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-02 psmith StatusNot A Bug Fixed
        Assigned toNone psmith
        Fixed ReleaseNone 4.4
        Triage StatusNone Medium Effort
    2022-09-25 psmith StatusNone Not A Bug
        Open/ClosedOpen Closed
    2022-09-23 psmith Component VersionNone 4.4
        Operating SystemNone Any

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code