GNU make 4.2.93 release candidate available

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

GNU make 4.2.93 release candidate available

Paul Smith-20
    --------------------------------------------------------------------
    GNU make is a tool which controls the generation of executables and
    other non-source files of a program from the program's source files.

    You can learn more at: https://www.gnu.org/software/make/
    --------------------------------------------------------------------

A new release candidate for GNU make 4.3 is available now for download:

    6b252188079b36d13e96d5527f8ca033  make-4.2.93.tar.lz
    929d4d3a216c02d0d86eb379356f4d1c  make-4.2.93.tar.gz

You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

- NEWS ----------------------------------------------------------------

Version 4.2.93 (03 Jan 2020)

A complete list of bugs fixed in this version is available here:

http://sv.gnu.org/bugs/index.php?group=make&report_id=111&fix_release_id=108&set=custom

* WARNING: Backward-incompatibility!
  Number signs (#) appearing inside a macro reference or function invocation
  no longer introduce comments and should not be escaped with backslashes:
  thus a call such as:
    foo := $(shell echo '#')
  is legal.  Previously the number sign needed to be escaped, for example:
    foo := $(shell echo '\#')
  Now this latter will resolve to "\#".  If you want to write makefiles
  portable to both versions, assign the number sign to a variable:
    H := \#
    foo := $(shell echo '$H')
  This was claimed to be fixed in 3.81, but wasn't, for some reason.
  To detect this change search for 'nocomment' in the .FEATURES variable.

* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a value
  starting with a space.  Now the initial space is only added if the variable
  already contains some value.  Similarly, appending an empty string does not
  add a trailing space.

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

* New feature: Grouped explicit targets
  Pattern rules have always had the ability to generate multiple targets with
  a single invocation of the recipe.  It's now possible to declare that an
  explicit rule generates multiple targets with a single invocation.  To use
  this, replace the ":" token with "&:" in the rule.  To detect this feature
  search for 'grouped-target' in the .FEATURES special variable.
  Implementation contributed by Kaz Kylheku <[hidden email]>

* New feature: .EXTRA_PREREQS variable
  Words in this variable are considered prerequisites of targets but they are
  not added to any of the automatic variable values when expanding the
  recipe.  This variable can either be global (applies to all targets) or
  a target-specific variable.  To detect this feature search for 'extra-prereqs'
  in the .FEATURES special variable.

* Makefiles can now specify the '-j' option in their MAKEFLAGS variable and
  this will cause make to enable that parallelism mode.

* GNU make will now use posix_spawn() on systems where it is available.
  If you prefer to use fork/exec even on systems where posix_spawn() is
  present, you can use the --disable-posix-spawn option to configure.  Aron
  Barath <[hidden email]> provided the basic implementation.

* Error messages printed when invoking non-existent commands have been cleaned
  up and made consistent.

* The previous limit of 63 jobs under -jN on MS-Windows is now
  increased to 4095.  That limit includes the subprocess started by
  the $(shell) function.

* A new option --no-silent has been added, that cancels the effect of the
  -s/--silent/--quiet flag.

* A new option -E has been added as a short alias for --eval.

* All wildcard expansion within GNU make, including $(wildcard ...), will sort
  the results.  See https://savannah.gnu.org/bugs/index.php?52076

* Interoperate with newer GNU libc and musl C runtime libraries.

* Performance improvements provided by Paolo Bonzini <[hidden email]>

GNU make Developer News

* Import the GNU standard bootstrap script to replace the hand-rolled
  "make update" method for building code from a GNU make Git repository.

* Rework the source distribution to move source files into the src/*
  subdirectory.  This aligns with modern best practices in GNU.

* Replace local portability code with Gnulib content.  Unfortunately due to a
  problem with Gnulib support for getloadavg, this forces a requirement on
  Automake 1.16 or above in order to build from Git.  See README.git.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Paul Smith-20
On Fri, 2020-01-03 at 02:42 -0500, Paul Smith wrote:
> A new release candidate for GNU make 4.3 is available now for download:
>
>     6b252188079b36d13e96d5527f8ca033  make-4.2.93.tar.lz
>     929d4d3a216c02d0d86eb379356f4d1c  make-4.2.93.tar.gz
>
> You can obtain a copy from:  https://alpha.gnu.org/gnu/make/

Unless something drastic changes this will be the final release candidate
for GNU make 4.3 and I plan to make the official release sometime this
week, perhaps Wednesday or Thursday.

If you want to test before the 4.3 release, please do so in the next few
days.  Or if there's a problem let me know.



Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Dennis Clarke
On 2020-01-05 16:20, Paul Smith wrote:

> On Fri, 2020-01-03 at 02:42 -0500, Paul Smith wrote:
>> A new release candidate for GNU make 4.3 is available now for download:
>>
>>      6b252188079b36d13e96d5527f8ca033  make-4.2.93.tar.lz
>>      929d4d3a216c02d0d86eb379356f4d1c  make-4.2.93.tar.gz
>>
>> You can obtain a copy from:  https://alpha.gnu.org/gnu/make/
>
> Unless something drastic changes this will be the final release candidate
> for GNU make 4.3 and I plan to make the official release sometime this
> week, perhaps Wednesday or Thursday.
>
> If you want to test before the 4.3 release, please do so in the next few
> days.  Or if there's a problem let me know.
>
>

Works neatly on ye old Solaris 10 sparcv9 with the Oracle C99 12.6
compiler and insanely strict CFLAGS. Even tossed in POSIXLY_CORRECT=1
at this.

The only nit, and it is a little nit, is the strange use of a three
parameter main() in src/main.c line 1054 and this is a "warning". Well
strictly speaking, pun intended, that isn't a terrible sin but it isn't
correct either. Sure, tossing in char **envp as the third rail on the
main() can work and usually does work it isn't supposed to work.

I looked in there and there is no good reason to not use getenv() but
who knows what voodoo to do in windows32?  I surely don't.

Looks like a good release after all these tests and years. Awesome.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Paul Smith-20
On Mon, 2020-01-06 at 05:33 -0500, Dennis Clarke wrote:
> The only nit, and it is a little nit, is the strange use of a three
> parameter main() in src/main.c line 1054 and this is a "warning". Well
> strictly speaking, pun intended, that isn't a terrible sin but it isn't
> correct either. Sure, tossing in char **envp as the third rail on the
> main() can work and usually does work it isn't supposed to work.
>
> I looked in there and there is no good reason to not use getenv() but
> who knows what voodoo to do in windows32?  I surely don't.

Just for clarity, getenv() isn't sufficient.  That requires that you know
what variables you want to look up: in GNU make we need to walk through all
the variables so we can import each one as a make variable.

In POSIX we can use extern char** environ instead.  On Windows you can use
_environ although my impression is that might not work everywhere (but it
might be good enough for make).  On other systems there may be other
things.

While the third arg to main isn't actually part of any standard, even
POSIX, it's actually very widely supported.


Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Mike Gran
In reply to this post by Paul Smith-20
On Fri, Jan 03, 2020 at 02:42:00AM -0500, Paul Smith wrote:
> A new release candidate for GNU make 4.3 is available now for download:

in your configure.ac, in the  'guile_versions="2.2 2.0 1.8" line.
There will be a guile 3.0 fairly soon.  I don't know if you want to add a
3.0 pre-emptively in that list, or wait until it is official.

I did build it with guile-3.0 with no issues, but, I didn't do any proper
testing.

Thanks,
Mike Gran

Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Dennis Clarke
In reply to this post by Paul Smith-20
On 2020-01-07 20:39, Paul Smith wrote:

> On Mon, 2020-01-06 at 05:33 -0500, Dennis Clarke wrote:
>> The only nit, and it is a little nit, is the strange use of a three
>> parameter main() in src/main.c line 1054 and this is a "warning". Well
>> strictly speaking, pun intended, that isn't a terrible sin but it isn't
>> correct either. Sure, tossing in char **envp as the third rail on the
>> main() can work and usually does work it isn't supposed to work.
>>
>> I looked in there and there is no good reason to not use getenv() but
>> who knows what voodoo to do in windows32?  I surely don't.
>
> Just for clarity, getenv() isn't sufficient.  That requires that you know
> what variables you want to look up: in GNU make we need to walk through all
> the variables so we can import each one as a make variable.
>
> In POSIX we can use extern char** environ instead.  On Windows you can use
> _environ although my impression is that might not work everywhere (but it
> might be good enough for make).  On other systems there may be other
> things.
>
> While the third arg to main isn't actually part of any standard, even
> POSIX, it's actually very widely supported.
>

Yep. Wrong and it seems to work anyways.

I was slightly surprised to get this latest alpha gmake 4.2.93 to
compile clean and test perfectly on old Solaris 10.  I keep around that
sort of hardware for production reasons and they are all legacy now. One
thing is true however and that is the OS is tightly standards compliant
and that includes the Oracle/Sun Studio 12.6 C99 compiler with obsessive
compulsive compliance flags. I nearly spit out my coffee. Clean. Every
damn line with the exception of a tiny little warning about "hey there
please don't use a third parameter to main(), thanks".


See ISO/IEC 9899:TC3 WG14/N1256 bloody C99 specifications section
5.1.2.2.1 Program Startup :

     The function called at program startup is named main. The
     implementation declares no prototype for this function. It shall
     be defined with a return type of int and with no parameters:

         int main(void) { /* ... */ }

     or with two parameters (referred to here as argc and argv, though
     any names may be used, as they are local to the function in which
     they are declared):

         int main(int argc, char *argv[]) { /* ... */ }

     or equivalent; 9) or in some other implementation-defined manner.

Right. However gmake tries int argc, char **argv, char **envp in
src/main.c at line 1054 and I am trying to care. I don't really.

For some reason you say GNU make needs to read in the entire users
environment? Really? OKay ... *shrug* ...

Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0 and
a whole slew of packages fail to build. We don't know why yet :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243145

Feels like progress to me regardless. I will stay in touch as I drag
this over multiple systems and architectures.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional






Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Paul Smith-20
On Fri, 2020-01-10 at 11:02 -0500, Dennis Clarke wrote:
> For some reason you say GNU make needs to read in the entire users
> environment? Really? OKay ... *shrug* ...

Sure; remember this:

https://www.gnu.org/software/make/manual/make.html#Environment

> Variables in make can come from the environment in which make is run.
> Every environment variable that make sees when it starts up is
> transformed into a make variable with the same name and value.

Of course, make COULD do this differently so that instead of importing
all the variables up-front, when a variable was expanded and no other
value could be found make could look up that variable in the
environment.  But, that's not how it works.  There are other issues
like making sure the $(origin ...) function worked correctly.  And of
course, the $(.VARIABLES) variable cannot be constructed.

And finally, we still need the environment (at least for some builds)
so that we can modify it then pass it to exec(2) as the environment of
the child process.

> Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0 and
> a whole slew of packages fail to build. We don't know why yet :
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243145

That's highly concerning.  Please let me know what you find out; I'd
prefer to understand this before publishing a release.

There are some backward-incompatible changes in this release but I'd
hoped that they would not be much of an issue in real life.


Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Paul Smith-20
In reply to this post by Dennis Clarke
On Fri, 2020-01-10 at 11:02 -0500, Dennis Clarke wrote:
> Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0 and
> a whole slew of packages fail to build.

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.

I will investigate this tonight.  Thanks for noticing this!


Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Paul Smith-20
On Fri, 2020-01-10 at 14:54 -0500, Paul Smith wrote:
> On Fri, 2020-01-10 at 11:02 -0500, Dennis Clarke wrote:
> > Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0
> > and
> > a whole slew of packages fail to build.
>
> 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.


Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Paul Smith-20
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".


Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Dennis Clarke
In reply to this post by Paul Smith-20
On 2020-01-10 14:54, Paul Smith wrote:

> On Fri, 2020-01-10 at 11:02 -0500, Dennis Clarke wrote:
>> Meanwhile a friend and I are giving 4.2.93 a look on FreeBSD 12.0 and
>> a whole slew of packages fail to build.
>
> 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.
>
> I will investigate this tonight.  Thanks for noticing this!
>

Just the sort of thing we do. I really do love the test suite in gnu
make but nothing beats the coffee pot draining horror show of trying to
build thirty thousand packages from source on FreeBSD. That can really
shake loose the most tiny corner cases. As for Solaris 10 on ye old
Fujitsu SPARC and the Oracle studio compilers, well gee, I just use that
to shake loose some obsessive compusive standards compliance stuff.
Which it does. Wonderfully and at great endless cost. Gotta love Oracle.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Martin Dorey-2
In reply to this post by Paul Smith-20
> 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=[hidden email]> on behalf of Paul Smith <[hidden email]>
Sent: Saturday, January 11, 2020 08:13
To: Dennis Clarke; [hidden email]
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:

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


Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Gnu - Make - Bugs mailing list
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

Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

Edward Welbourne-3
On 2020-01-11 13:22, Martin Dorey wrote:
>> 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.

Dennis Clarke (11 January 2020 22:09) replied
> 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?

Sounds like a sane plan to me - give folk at least one release's warning
before making a change that (we now know) will break existing make
files.  Painful to not be able to simply fix the bug, but pragmatic.

        Eddy.

Reply | Threaded
Open this post in threaded view
|

Re: GNU make 4.2.93 release candidate available

John Marshall-2
In reply to this post by Paul Smith-20
I am the OP whose seemingly innocuous bug report (40657) has led to this mess. Unfortunately I don't recall what I was doing back in 2013, but I suspect I had naively written a suffix rule with a prerequisite that didn't work as expected, noted that the documentation said something else again, filed a documentation buglet, and recoded my makefile some other way.

Having explored this further today, I now think the 4.2.1&prior behaviour is mostly sensible in producing both a target rule and a suffix rule, but less so in how it treats the prerequisite(s).

On 11 Jan 2020, at 16:12, Paul Smith <[hidden email]> wrote:

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

The GNU Make 4.2.1&prior behaviour differs depending on whether the putative suffixes are listed in .SUFFIXES:

$ cat Makefile
.SUFFIXES:
.SUFFIXES: .one .two

.one.two: fred.txt
        cat $? > $@

.foo.rc: fred.txt
        cat $? > $@

make -p | grep -C5 'cat '
[snip]
%.two: %.one
#  recipe to execute (from 'Makefile', line 5):
        cat $? > $@
--
.foo.rc: fred.txt
#  Implicit rule search has not been done.
#  Modification time never checked.
#  File has not been updated.
#  recipe to execute (from 'Makefile', line 8):
        cat $? > $@
--
.one.two: fred.txt
#  Implicit rule search has not been done.
#  Modification time never checked.
#  File has not been updated.
#  recipe to execute (from 'Makefile', line 5):
        cat $? > $@

Thus as .foo and .rc are not in .SUFFIXES, Make has treated ".foo.rc: fred.txt" solely as an ordinary target rule. However it has considered that the .one.two rule could be either a suffix rule (with a non-POSIXly-blessed prerequisite) or a target rule, so Make has ingested it both ways (which is bogus but also very pragmatic!).

This means that a diagnostic could be produced when ingesting this both ways ("warning: ignoring POSIX-prohibited prerequisite on suffix rule") but happily that would not be produced for legitimate target rule cases like .foo.rc. Hopefully most such initial-dot legitimate targets would have components that are not listed in .SUFFIXES so would escape the warning.

>>  .man.1: Makefile
>>          $(MANGEN) $< >$@
>
> 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.
[...]
> 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.

Agreed, so I did a little exploration of other makes.

For the Makefile above, OpenBSD's make (as shown by `make -p | grep -C5 'cat '` again) treats .one.two as a suffix rule (only) and .foo.rc as a target rule. However running the makefile shows that both rules have fred.txt as a prerequisite:

$ touch barney.one; rm fred.txt
$ make barney.two
make: don't know how to make fred.txt (prerequisite of: barney.two)
Stop in /home/johnm/test
$ make .foo.rc
make: don't know how to make fred.txt (prerequisite of: .foo.rc)
Stop in /home/johnm/test
$ touch fred.txt
$ make barney.two
cat barney.one fred.txt > barney.two
$ make .foo.rc
cat fred.txt > .foo.rc
$ make .one.two  # demonstrates not interpreted as a target rule
make: don't know how to make .one.two
Stop in /home/johnm/test

This suggests that OpenBSD's make in fact has an extension over POSIX in that it does treat Makefile as a prerequisite of %.1 in the .man.1 suffix rule quoted above.

It's unclear from Illumos's /usr/bin/make's -p output how it's treating the two rules. Running the makefile appears to show that it's treating .one.two as both a suffix rule (without a prerequisite) and a target rule (with the prerequisite):

$ touch barney.one; rm fred.txt
$ make barney.two
cat barney.one > barney.two
$ make .foo.rc
make: Fatal error: Don't know how to make target `fred.txt'
$ make .one.two
make: Fatal error: Don't know how to make target `fred.txt'
$ touch fred.txt
$ make .foo.rc
cat fred.txt > .foo.rc
$ make .one.two
cat fred.txt > .one.two

Illumos's /usr/xpg4/bin/make and /usr/bin/dmake behave similarly.

Presumably then Dennis's failing FreeBSD packages are all cases of "no rule to make foobar.1" as GNU Make 4.2.93 has removed the suffix rule interpretation of rules like ".man.1: Makefile", and these in fact work as intended in the BSDs' makes due to the extension observed above.

So it seems like there are three possible approaches:

(A) Revert to the 4.2.1&prior behaviour, and clarify the GNU Make documentation now that we understand what all's going on. Then these makefiles will work as expected when building from a clean directory (though will not rebuild foobar.1 as intended when Makefile is touched).

(B) Consider the BSD make behaviour as sufficient precedent to implement an extension to POSIX to accept prerequisites on suffix rules (only in non-POSIX mode; when .POSIX is in the makefile, this should be a warning or even an error -- except that the Illumos/GNU precedent is to say "maybe this is a funny target name not a suffix rule"). Unfortunately this involves additional work.

(C) Revert to the 4.2.1&prior behaviour and add a warning ("ignoring prerequisite on suffix rule") as discussed. Then these makefiles will work as expected when building from a clean directory (though will not rebuild foobar.1 as intended when Makefile is touched).

I didn't immediately find any motivation for forbidding prerequisites on inference rules in the POSIX description of make or in the Austin Group bug tracker.

If I were going to favour one of these options (without considering the work involved), it would be (B) silently accepting suffix rule prerequisites in non-POSIX mode for compatibility with BSD make, and in POSIX mode emitting a warning and one of accepting the prerequisite / ignoring the prerequisite / ingesting the rule as a target rule only.

Cheers (and apologies for the inconvenience!),

    John