On 2020-01-11 13:22, Martin Dorey wrote: >> accept prerequisites and implement them as > the user expects, which violates POSIX ... and which never happened > before > > I fear implementing what the makefile author asked for instead of > what they got... could expose other latent issues in their makefile. > >> Martin had suggested some kind of warning > > I’m glad Paul remembers because I struggled to find > https://savannah.gnu.org/bugs/?40657 before recalling it. > That let me find the makefiles I’d had to fix. . . . > > Still, I favor a third option: restoring the previous, accidental > behavior - treating the rule as a suffix rule with no prerequisites > - but generating a warning about it. Paul rightly prefers the > posix-mandated behavior but it’s not like anyone’s really agitating > for the posix behavior on such obscure filenames, right? > Keeping the new, correct behavior in the .POSIX case, with no > warning, that might fly, as long as none of Dennis’s myriad failing > builds use .POSIX. I can imagine Paul finding this third option > depressing but I think the real value here is in telling the > maintainer that their makefile is broken rather than in fixing a > posix conformance corner case that no one ever noticed.
I would like to make the suggestion here that it is entirely reasonable after a four year release stretch to build in a warning. Such a trivial warning would give people time to fix the error of their Makefile ways while also allowing for the world to keep on building software. At the very least it shows the software maintainers that there are to be no sudden surprises when the next release of GNU Make comes along and it will actually enforce the correct behavior. My hope is that the time to that next release is at least six months. What say you all to such a compromise? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
