Bug 243145
| Summary: | devel/gmake: alpha 4.2.93 test | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Steve Wills <swills> | ||||
| Component: | Ports Framework | Assignee: | Steve Wills <swills> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Only Me | CC: | dclarke, ports-bugs | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(tijl) swills: exp-run? |
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Some new failures on 12.0 amd64: http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/dpkg-1.19.7.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/dcd-0.99.2_2.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/stress-ng-0.10.15.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/infernal-1.1.2.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/mothur-1.43.0.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/clixon-4.1.0.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/libdsp-5.0.2_3.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/libopencm3-0.0.20190111.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/ptlib-2.10.11_4.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/sheerdns-1.04.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/mame-0.209_1.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/mess-0.209_1.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/fr-med-4.0.0.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/axel-2.4_2.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/weex-2.8.2_1.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/crimson-fields-0.5.3_5.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/pinball-0.3.4.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/xtux-20030306.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/flasm-1.62.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/gocr-0.52.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/cparser-0.9.14.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/ecl-15.3.7_5.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/cyrus-imapd30-3.0.13.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/libtommath-1.2.0.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/gstreamer-plugins-0.10.36_12,3.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/gstreamer1-1.14.4.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/kismet-2016.07.r1_2,1.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/gopher-3.0.6_1.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/sslh-1.20.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/ADMsmb-0.3.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/n2n-2.4.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/nettle-3.5.1_1.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/torque-2.5.13_2,1.log http://package18.nyi.freebsd.org/data/120amd64-default-PR241624/2020-01-09_21h17m48s/logs/blt-2.5.3_4.log Lots of ports were skipped due to security/nettle, multimedia/gstreamer1, multimedia/gstreamer-plugins 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 this. 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 created). 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: .POSIX: .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 RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional 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 RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional 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. Dennis Closing for now, will let maintainer (tijl) deal with it when ready. |
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.