bug-make
[Top][All Lists]
Advanced

[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: Fri, 10 Jan 2020 15:07:08 -0500

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 via email to

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