[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU make 4.2.93 release candidate available

From: Martin Dorey
Subject: Re: GNU make 4.2.93 release candidate available
Date: Sat, 11 Jan 2020 18:22:10 +0000

> 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.  I see I moved the prerequisites from .c.o to a new $(OBJS): $(HEADERS), keeping the .c.o rule to minimize the chance of breaking anything else.  So I did do as Paul’s first suggestion and, despite my above fear, got away with it.

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.  If all Dennis’s failing builds told us that this was definitely the problem, that’d be a significant help, even for this audience.

From: Bug-make <bug-make-bounces+martin.dorey=address@hidden> on behalf of Paul Smith <address@hidden>
Sent: Saturday, January 11, 2020 08:13
To: Dennis Clarke; address@hidden
Subject: Re: GNU make 4.2.93 release candidate available
***** EXTERNAL EMAIL *****

On Fri, 2020-01-10 at 15:07 -0500, Paul Smith wrote:
> 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.

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".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]