Bug 243145 - devel/gmake: alpha 4.2.93 test
Summary: devel/gmake: alpha 4.2.93 test
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Steve Wills
Depends on:
Reported: 2020-01-07 00:43 UTC by Steve Wills
Modified: 2020-02-06 18:30 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (tijl)
swills: exp-run?

patch to update to 4.2.93 (8.24 KB, patch)
2020-01-07 00:43 UTC, Steve Wills
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Wills freebsd_committer 2020-01-07 00:43:13 UTC
Created attachment 210491 [details]
patch to update to 4.2.93

Here's a patch to update gmake to the alpha version, just for testing. Would like to see an exp-run to test it.
Comment 1 Antoine Brodin freebsd_committer 2020-01-10 12:12:38 UTC
Some new failures on 12.0 amd64:


Lots of ports were skipped due to security/nettle, multimedia/gstreamer1, multimedia/gstreamer-plugins
Comment 2 Dennis Clarke 2020-01-11 17:00:01 UTC
This just in from Paul Smith and our GNU make friends : 

Sender: "Bug-make" <bug-make-bounces+dclarke=blastwave.org@gnu.org>
I can reproduce these failures trying to build dpkg 1.19.7 on
GNU/Linux with the new make.  Ugh!!

There seems to be some issue with old-style suffix rules.

Oh.  It's this change:

* WARNING: Backward-incompatibility!
  Contrary to the documentation, suffix rules with prerequisites were being
  treated BOTH as simple targets AND as pattern rules.  Behavior now matches
  the documentation, and pattern rules are no longer created in this case.

Hm.  That might be too incompatible a change.  I'll need to consider

These makefiles all seem to have rules like this:

  .man.1: Makefile
          $(MANGEN) $< >$@
  .man.5: Makefile
          $(MANGEN) $< >$@
  .man.7: Makefile
          $(MANGEN) $< >$@
  .man.8: Makefile
          $(MANGEN) $< >$@

This is illegal according to POSIX:
    Inference rules are formatted as follows:
    The application shall ensure that the makefile does not specify
    prerequisites for inference rules; no characters other than white
    space shall follow the <colon> in the first line

So the correct way to write this in portable make syntax is remove the
Makefile prerequisite from the suffix rule, then add:

  $(man_MANS): Makefile

(assuming that man_MANS contains a list of all the man pages to be

However, this practice may be so wide-spread that we have to allow it,
perhaps unless .POSIX is specified.

So regardless, we have a change here and it breaks the build
situation where it may be partially the Makefile(s) and partially
an incompatible back-breaking change.

however ........

Hm hm.

So it turns out to be even more bogus.  I re-read the bug and it turns out
that the prerequisites here were ignored before.  So, these rules did not
do at all what the author (presumably) intended.

If you built targets with a suffix rule with a prerequisite, then you
touched one of the prerequisites, then you re-ran make (I'm talking about
4.2.1 or below not with the new changes), it would not rebuild anything.

To me this makes preserving the old behavior quite problematic: make is
allowing you to write illegal makefiles with no warning or error, which is
very bad IMO.

I think that either make should accept prerequisites and implement them as
the user expects, which violates POSIX and so should only be enabled if
.POSIX is not set (and which never happened before and so would be extra
work), or else we should keep the new behavior and follow POSIX and
existing makefiles will fail as we've discovered.

To me the former is useless.  The only reason to use suffix rules is to be
portable with other versions of make: if you're using GNU make then pattern
rules are infinitely more flexible and usable.  And if there's no other
reason to use suffix rules except to be portable then we shouldn't be
implementing non-portable capabilities for it.

If we do the latter, Martin had suggested some kind of warning or
diagnostic be shown if a makefile contained an incorrectly-constructed
suffix rule.  At the time I didn't think this would be a widespread problem
so I didn't agree, but perhaps I was wrong.  It's a bit annoying that a
warning would be generated for perfectly legitimate makefile (albeit
confusing and _likely_ wrong).

I mean, it's not _illegal_ to have:

   .SUFFIXES: .f .b
   .f.b : prereq

it just means that ".f.b" is not a suffix rule, it's a real rule to build
the literal target ".f.b".

OKay .. so it may be better to "fix" the existing Makefiles. 

Dennis Clarke
UNIX and Linux spoken
GreyBeard and suspenders optional
Comment 3 Dennis Clarke 2020-01-11 21:17:58 UTC

At this time I am suggesting a warning be issued by the new GNU Make
and that the previous behavior be allowed even though we know that it
is not strictly correct. Given that there has been a four year stretch
between the releases this seems reasonable. However some future release
will enforce the correct behavior and thus there will be time for folks
to correct their Makefile(s). 

I will keep this bug up to date and let Steve know what is going on.

Dennis Clarke
UNIX and Linux spoken
GreyBeard and suspenders optional
Comment 4 Dennis Clarke 2020-01-27 19:37:15 UTC

Sadly we have a release of gnu make 4.3 just a few days ago and in my
initial tests it fails its own testsuite on Red Hat Enterprise Linux 7.4
and I have yet to embrace it elsewhere.

I will look into this later this week. 

Comment 5 Steve Wills freebsd_committer 2020-02-06 18:30:42 UTC
Closing for now, will let maintainer (tijl) deal with it when ready.