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.

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.

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.