Re: GNU make 4.2.93 release candidate available

[Dennis Clarke]

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