[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU make 4.2.93 release candidate available
From: |
Paul Smith |
Subject: |
Re: GNU make 4.2.93 release candidate available |
Date: |
Sat, 11 Jan 2020 11:12:59 -0500 |
User-agent: |
Evolution 3.34.1-2 |
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:
.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".
- GNU make 4.2.93 release candidate available, Paul Smith, 2020/01/03
- Re: GNU make 4.2.93 release candidate available, Paul Smith, 2020/01/05
- Re: GNU make 4.2.93 release candidate available, Dennis Clarke, 2020/01/06
- Re: GNU make 4.2.93 release candidate available, Paul Smith, 2020/01/07
- Re: GNU make 4.2.93 release candidate available, Dennis Clarke, 2020/01/10
- Re: GNU make 4.2.93 release candidate available, Paul Smith, 2020/01/10
- Re: GNU make 4.2.93 release candidate available, Paul Smith, 2020/01/10
- Re: GNU make 4.2.93 release candidate available, Paul Smith, 2020/01/10
- Re: GNU make 4.2.93 release candidate available,
Paul Smith <=
- Re: GNU make 4.2.93 release candidate available, Martin Dorey, 2020/01/11
- Re: GNU make 4.2.93 release candidate available, Dennis Clarke, 2020/01/11
- Re: GNU make 4.2.93 release candidate available, Edward Welbourne, 2020/01/13
- Re: GNU make 4.2.93 release candidate available, John Marshall, 2020/01/13
- Re: GNU make 4.2.93 release candidate available, Dennis Clarke, 2020/01/11
Re: GNU make 4.2.93 release candidate available, Mike Gran, 2020/01/07