Re: GNU Make 4.4 released!

2022-11-08 Thread KO Myung-Hun
Hi/2.

Paul Smith wrote:
> On Mon, 2022-11-07 at 20:40 +0900, KO Myung-Hun wrote:
>> May I take over OS/2 port maintenance ?
>> For this, what should I do ?
> 
>1. Subscribe to this mailing list and announce your intention to
>   work on this (to prevent possible duplication of effort).

Already done.

>2. Download the latest release (currently GNU Make 4.4).
>3. Get it to compile on OS/2 and, if possible, run the regression
>   test suite (if you have Perl on OS/2).
>4. If you can't run the regression test suite, then generate your
>   own set of tests (for example some other software that you can
>   use GNU Make to build, especially software that makes use of GNU
>   Make features).

I've built successfully with a little changes. I'll try to run
regression test suite later.

>5. Once you're satisfied that it works properly, post a patch or set
>   of patches for the changes you needed to make to get it working,
>   to this mailing list.
>6. Likely there will need to be a conversation about the best way to
>   address various issues so be prepared to rework your changes if
>   necessary.

Ok, I'll post later.

>7. If your changes are at all extensive, you will need to fill out
>   paperwork to assign copyright for your changes to the FSF, and
>   your employer (if they have rights to your work which most do)
>   will need to approve this as well. Contact me to get the needed
>   paperwork.

I have this already for GNU Make.

>8. Commit to testing and updating the port when new prereleases of
>   GNU Make are announced.
> 
> That's pretty much it.
> 
> You should consider carefully whether it's really worthwhile to make
> this effort. Presumably there is already some version of GNU Make that
> works on OS/2 and can be used there which satisfies all current needs.
> That version obviously will continue to be available: no one is
> suggesting changing published versions.
> 

I know. And I'm already maintaining GNU Make v3.81 for OS/2 at
https://github.com/komh/make-os2. I'll try to merge the patches in there.

> Most of the new features available in GNU Make, such as Guile support,
> dynamic object loading, jobserver, output sync, etc. almost certainly
> can't be made to work on OS/2 and so will just need to be disabled. So
> the question is, is keeping this port up-to-date a good use of
> resources?
> 

I think so. And if some projects requires newer GNU Make, working on GNU
Make at that time needs more resources.

> Of course, only the OS/2 users can answer this question.
> 
> If you decide it is worthwhile, and you have the bandwidth and ability
> to do it, then welcome aboard!

I willing to do.

Thanks!

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM

Korean OS/2 User Community : http://www.os2.kr/




Re: GNU Make 4.4 released!

2022-11-07 Thread KO Myung-Hun
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi/2.

Paul Smith wrote:
> 
>
>
> 
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/ 
> 
>
>
> 
The next stable release of GNU make, 4.4, is available now for
> download:
> 
> 5da8b0fcc500de9c254ca59e58558b27  make-4.4.tar.lz 
> d7575a26a94ee8427130e9db23cdaa78  make-4.4.tar.gz
> 
> You can obtain a copy from: https://ftp.gnu.org/gnu/make/?C=M;O=D
> You can choose a nearby mirror:
> https://ftpmirror.gnu.org/make/ A list of mirror sites is
> available:  https://www.gnu.org/order/ftp.html
> 
> - NEWS 
> 
>
>
> 
Version 4.4 (31 Oct 2022)
> 
> A complete list of bugs fixed in this version is available here:
> 
> https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=109=custom
>
>
> 
* WARNING: Deprecation! The following systems are deprecated in
> this release: - OS/2 (EMX) - AmigaOS - Xenix - Cray In the NEXT 
> release of GNU Make, support for these systems will be removed. If 
> you want to see them continue to be supported, contact 
> .
> 

May I take over OS/2 port maintenance ?

For this, what should I do ?

- -- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v6.1.40 on Intel Core i7-3615QM 2.30GHz with 12GB RAM

Korean OS/2 User Community : http://www.os2.kr/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (OS/2)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFjaO6mE9YstvghgroRAkVsAJ9ouiaxfYrwo0AKwdrfA+mfEzbSZwCgsJyA
8paDaNaM5KXAEQxh49e2BYQ=
=2AJ7
-END PGP SIGNATURE-



Re: GNU Make 4.4 released!

2022-11-07 Thread Paul Smith
On Mon, 2022-11-07 at 20:40 +0900, KO Myung-Hun wrote:
> May I take over OS/2 port maintenance ?
> For this, what should I do ?

   1. Subscribe to this mailing list and announce your intention to
  work on this (to prevent possible duplication of effort).
   2. Download the latest release (currently GNU Make 4.4).
   3. Get it to compile on OS/2 and, if possible, run the regression
  test suite (if you have Perl on OS/2).
   4. If you can't run the regression test suite, then generate your
  own set of tests (for example some other software that you can
  use GNU Make to build, especially software that makes use of GNU
  Make features).
   5. Once you're satisfied that it works properly, post a patch or set
  of patches for the changes you needed to make to get it working,
  to this mailing list.
   6. Likely there will need to be a conversation about the best way to
  address various issues so be prepared to rework your changes if
  necessary.
   7. If your changes are at all extensive, you will need to fill out
  paperwork to assign copyright for your changes to the FSF, and
  your employer (if they have rights to your work which most do)
  will need to approve this as well. Contact me to get the needed
  paperwork.
   8. Commit to testing and updating the port when new prereleases of
  GNU Make are announced.

That's pretty much it.

You should consider carefully whether it's really worthwhile to make
this effort. Presumably there is already some version of GNU Make that
works on OS/2 and can be used there which satisfies all current needs.
That version obviously will continue to be available: no one is
suggesting changing published versions.

Most of the new features available in GNU Make, such as Guile support,
dynamic object loading, jobserver, output sync, etc. almost certainly
can't be made to work on OS/2 and so will just need to be disabled. So
the question is, is keeping this port up-to-date a good use of
resources?

Of course, only the OS/2 users can answer this question.

If you decide it is worthwhile, and you have the bandwidth and ability
to do it, then welcome aboard!



Re: Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

2022-10-31 Thread Paul Smith
On Mon, 2022-10-31 at 11:06 +0100, Alejandro Colomar wrote:
> On 10/31/22 08:01, Paul Smith wrote:
> > * New feature: The .WAIT special target
> 
> I'm curious: what is .WAIT made for?

As mentioned in the NEWS, it's _primarly_ there because the next
release of the POSIX spec will require a POSIX-conforming make utility
to support it.

> Isn't it just a workaround for broken dependencies?

Fundamentally I agree with you, that .WAIT is a poor workaround for a
true prerequisite statement, and is hard to use in a reliable way.

I made this case to the POSIX folks.  However, the .WAIT facility with
its current behavior has been available in BSD versions of make for a
very long time and is widely used there.  It tends to be used more for
things like the FreeBSD Ports build system where you're declaring
higher-level targets to be waited on so it's simpler to reason about.

>   I mean, considering the following example:
> 
>  all: one two .WAIT three
>  one two three: ; @sleep 1; echo $@
> 
> It's the same as if it was written as
> 
>  all: one two three
>  three: one two
>  one two three: ; @sleep 1; echo $@
> 
> Isn't it?

As Eddy points out it's not identical in behavior.  Fundamentally .WAIT
does not add any new edges to the DAG that make constructs, so there is
nothing inherent to the target "three" (in your example) that connects
it to "one" or "two".  The "wait-ness" is a function of the _target_
(all), not the prerequisites at all.  And, it's specific to that
target.  So if you have:

  foo: one .WAIT two
  bar: one two

then if you run "make -j foo" make will wait for "one" to complete
before running "two", but if you run "make -j bar" then it will not.

Even more annoyingly, if you have:

  all: foo bar
  foo: one .WAIT two
  bar: one two

and you run "make -j all" then "one" and "two" will be run concurrently
because even though when make wants to build "foo" it will wait to
start "two", when make wants to build "bar" concurrently with "foo"
then "one" and "two" will run concurrently.

So like I said, IMO .WAIT is a suboptimal capability that is hard to
use reliably and probably isn't very useful compared to other ordering
capabilities that GNU make already has.

But, it is very easy to use, is required by POSIX, and there are a lot
of makefiles that want to use it.

So now they can.

> > * New feature: .NOTPARALLEL accepts prerequisites
> 
> But my useful question comes with .NOTPARALLEL, which I think can be
> useful for something I asked some time ago, and can't be done with
> pre-4.4 make.
> 
> The documentation is a bit unclear on the exact details of this
> feature, by writing it in terms of .WAIT.
> 
> Let's say I have the following:
> 
>  all: a b c
>  .NOTPARALLEL: b
>  a: b c
>  a b c: ; @sleep 1; echo $@
> 
> Is it guaranteed that b will be run either before or after c but
> never at the same time?  Please clarify the manual regarding this. 
> Maybe this example is good for the docs.

No.  In the makefile above, .NOTPARALLEL has exactly zero effect.  The
manual says:

   This implicitly adds a .WAIT between each prerequisite of the listed
   targets.

I think this is pretty clear.  You might be confusing yourself by
hoping this provides some capability that it doesn't and so reading
things into the manual beyond what it actually says.

Probably an example would be helpful in the manual, but in your snippet
above you don't list any prerequisites for "b", so ".NOTPARALLEL: b",
which adds .WAIT between each prerequisite, is a no-op.

If you had this:

  .NOTPARALLEL: b
  b: x y z

it would be identical to writing:

  b: x .WAIT y .WAIT z

and exactly that, nothing else.

> The usefulness of something like this is that b might run a command
> that asks for a password, and I want literraly _everything_ else on
> hold while a program is asking for a password.

That is not how it works.

I don't believe that such a requirement can or should be met by some
form of .NOTPARALLEL.  If we wanted to create such a thing the way I
would do it is create a new special target like ".PREMAKE" or whatever,
and all the prerequisites of that special target would be guaranteed to
be updated first, before any other target, regardless of the goal
targets.

Or, something like that.  Details would need to be considered.

> I guess shuffle doesn't mess with .NOTPARALLEL or .WAIT.  Just to
> confirm.

I'm not sure what you mean by "mess with", but they have no
relationship to each other.

> > * New feature: The --jobserver-style command line option and named
> > pipes
> 
> Another curious question:  Does this fifo jobserver allow
> .NOTPARALLEL even with recursive makes?

It has no relationship to .NOTPARALLEL which continues to be confined
to a single instance of make.  I don't even really understand what it
would mean to have .NOTPARALLEL cross recursive makes.



Re: Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

2022-10-31 Thread Alejandro Colomar

Hi Eddy,

On 10/31/22 14:52, Edward Welbourne wrote:

I mean, considering the following example:

    all: one two .WAIT three
    one two three: ; @sleep 1; echo $@

It's the same as if it was written as

    all: one two three
    three: one two
    one two three: ; @sleep 1; echo $@

Isn't it?


On 10/31/22 13:42, Edward Welbourne wrote:

Only from the point of view of make all; try make three and you'll see
the difference.

If you make three with the first make file, it'll take one second and
just echo three.  Passing -j 37 will make no difference.  If you make
three with the second make file, it'll take at least two seconds (three
with -j1) and output one and two (in some order) then three.

If you make all with the either makefile, it'll behave like make three
with the second makefile, but differently from make three with the first
makefile.

If any other targets depend on three, they're likewise changed by the
second makefile, compared to the first,


Alejandro Colomar (Monday, October 31, 2022 13:46) replied:

Ahh, sure, that's right.

However, I don't see why this would be beneficial.  Why would A need
to be built before B, if there's no dependency between them?


If each of them needs to lock some resource to do its job, you don't
want them to be run in parallel.  For example, each of them appends to a
common log file, and you don't want their log entries interleaved; or
each updates a database with a new record relating to the present build.
Cases like this are also relevant to .NOT_PARALLEL; you might not care
what order the entries are processed in, just so long as no two of them
are trying to run at the same time.

That probably applies to all sorts of resources that take incremental
updates; make is a tool for doing the sorts of update that completely
rewrite a file, not the sort that add entries incrementally.

I have no doubt users of make will discover a plethora of other ways
that this is useful.


I think this is hiding some kind of missing dependency.  Maybe this is
a workaround for not having post-requisites yet?


While it might be used as a kludge-around for some such cases, it has
uses that cannot be represented faithfully be dependencies and really
just come down to "these two targets should not be built in parallel".


Thanks a lot for the detailed example!  It makes sense.

Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature


Re: Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

2022-10-31 Thread Edward Welbourne
>>> I mean, considering the following example:
>>>
>>>   all: one two .WAIT three
>>>   one two three: ; @sleep 1; echo $@
>>>
>>> It's the same as if it was written as
>>>
>>>   all: one two three
>>>   three: one two
>>>   one two three: ; @sleep 1; echo $@
>>>
>>> Isn't it?

On 10/31/22 13:42, Edward Welbourne wrote:
>> Only from the point of view of make all; try make three and you'll see
>> the difference.
>> 
>> If you make three with the first make file, it'll take one second and
>> just echo three.  Passing -j 37 will make no difference.  If you make
>> three with the second make file, it'll take at least two seconds (three
>> with -j1) and output one and two (in some order) then three.
>> 
>> If you make all with the either makefile, it'll behave like make three
>> with the second makefile, but differently from make three with the first
>> makefile.
>> 
>> If any other targets depend on three, they're likewise changed by the
>> second makefile, compared to the first,

Alejandro Colomar (Monday, October 31, 2022 13:46) replied:
> Ahh, sure, that's right.
>
> However, I don't see why this would be beneficial.  Why would A need
> to be built before B, if there's no dependency between them?

If each of them needs to lock some resource to do its job, you don't
want them to be run in parallel.  For example, each of them appends to a
common log file, and you don't want their log entries interleaved; or
each updates a database with a new record relating to the present build.
Cases like this are also relevant to .NOT_PARALLEL; you might not care
what order the entries are processed in, just so long as no two of them
are trying to run at the same time.

That probably applies to all sorts of resources that take incremental
updates; make is a tool for doing the sorts of update that completely
rewrite a file, not the sort that add entries incrementally.

I have no doubt users of make will discover a plethora of other ways
that this is useful.

> I think this is hiding some kind of missing dependency.  Maybe this is
> a workaround for not having post-requisites yet?

While it might be used as a kludge-around for some such cases, it has
uses that cannot be represented faithfully be dependencies and really
just come down to "these two targets should not be built in parallel".

Eddy.



Re: Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

2022-10-31 Thread Edward Welbourne
On 10/31/22 08:01, Paul Smith wrote:
>> * New feature: The .WAIT special target
>>    If the .WAIT target appears between two prerequisites of a target, then
>>    GNU Make will wait for all of the targets to the left of .WAIT in the list
>>    to complete before starting any of the targets to the right of .WAIT.
>>    This feature is available in some other versions of make, and it will be
>>    required by an upcoming version of the POSIX standard for make.
>>    Different patches were made by Alexey Neyman  
>>(2005)
>>    and Steffen Nurpmeso  (2020) that were useful but the
>>    result is a different implementation (closer to Alexey's idea).

Alejandro Colomar (Monday, October 31, 2022 11:06) replied:
> I'm curious: what is .WAIT made for?  Isn't it just a workaround for
> broken dependencies?

No.

> I mean, considering the following example:
>
>  all: one two .WAIT three
>  one two three: ; @sleep 1; echo $@
>
> It's the same as if it was written as
>
>  all: one two three
>  three: one two
>  one two three: ; @sleep 1; echo $@
>
> Isn't it?

Only from the point of view of make all; try make three and you'll see
the difference.

If you make three with the first make file, it'll take one second and
just echo three.  Passing -j 37 will make no difference.  If you make
three with the second make file, it'll take at least two seconds (three
with -j1) and output one and two (in some order) then three.

If you make all with the either makefile, it'll behave like make three
with the second makefile, but differently from make three with the first
makefile.

If any other targets depend on three, they're likewise changed by the
second makefile, compared to the first,

Eddy.



Re: Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

2022-10-31 Thread Alejandro Colomar

Hi Eddy,

On 10/31/22 13:42, Edward Welbourne wrote:

Alejandro Colomar (Monday, October 31, 2022 11:06) replied:

I'm curious: what is .WAIT made for?  Isn't it just a workaround for
broken dependencies?


No.


I mean, considering the following example:

  all: one two .WAIT three
  one two three: ; @sleep 1; echo $@

It's the same as if it was written as

  all: one two three
  three: one two
  one two three: ; @sleep 1; echo $@

Isn't it?


Only from the point of view of make all; try make three and you'll see
the difference.

If you make three with the first make file, it'll take one second and
just echo three.  Passing -j 37 will make no difference.  If you make
three with the second make file, it'll take at least two seconds (three
with -j1) and output one and two (in some order) then three.

If you make all with the either makefile, it'll behave like make three
with the second makefile, but differently from make three with the first
makefile.

If any other targets depend on three, they're likewise changed by the
second makefile, compared to the first,


Ahh, sure, that's right.

However, I don't see why this would be beneficial.  Why would A need to be built 
before B, if there's no dependency between them?  I think this is hiding some 
kind of missing dependency.  Maybe this is a workaround for not having 
post-requisites yet?


Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature


Doubts about .WAIT and .NOTPARALLEL (was: GNU Make 4.4 released!)

2022-10-31 Thread Alejandro Colomar

Hi Paul,

On 10/31/22 08:01, Paul Smith wrote:



* New feature: The .WAIT special target
   If the .WAIT target appears between two prerequisites of a target, then
   GNU Make will wait for all of the targets to the left of .WAIT in the list
   to complete before starting any of the targets to the right of .WAIT.
   This feature is available in some other versions of make, and it will be
   required by an upcoming version of the POSIX standard for make.
   Different patches were made by Alexey Neyman  (2005)
   and Steffen Nurpmeso  (2020) that were useful but the
   result is a different implementation (closer to Alexey's idea).


I'm curious: what is .WAIT made for?  Isn't it just a workaround for broken 
dependencies?  I mean, considering the following example:


all: one two .WAIT three
one two three: ; @sleep 1; echo $@

It's the same as if it was written as

all: one two three
three: one two
one two three: ; @sleep 1; echo $@

Isn't it?



* New feature: .NOTPARALLEL accepts prerequisites
   If the .NOTPARALLEL special target has prerequisites then all prerequisites
   of those targets will be run serially (as if .WAIT was specified between
   each prerequisite).


But my useful question comes with .NOTPARALLEL, which I think can be useful for 
something I asked some time ago, and can't be done with pre-4.4 make.


The documentation is a bit unclear on the exact details of this feature, by 
writing it in terms of .WAIT.


Let's say I have the following:

all: a b c
.NOTPARALLEL: b
a: b c
a b c: ; @sleep 1; echo $@

Is it guaranteed that b will be run either before or after c but never at the 
same time?  Please clarify the manual regarding this.  Maybe this example is 
good for the docs.


The usefulness of something like this is that b might run a command that asks 
for a password, and I want literraly _everything_ else on hold while a program 
is asking for a password.


Of course, all this is without recursive make, I know.


* New feature: The --shuffle command line option
   This option reorders goals and prerequisites to simulate non-determinism
   that may be seen using parallel build.  Shuffle mode allows a form of "fuzz
   testing" of parallel builds to verify that all prerequisites are correctly
   described in the makefile.
   Implementation provided by Sergei Trofimovich 


I guess shuffle doesn't mess with .NOTPARALLEL or .WAIT.  Just to confirm.



* New feature: The --jobserver-style command line option and named pipes
   A new jobserver method is used on systems where mkfifo(3) is supported.
   This solves a number of obscure issues related to using the jobserver
   and recursive invocations of GNU Make.  This change means that sub-makes
   will connect to the jobserver even if they are not marked as recursive.
   It also means that other tools that want to participate in the jobserver
   will need to be enhanced as described in the GNU Make manual.
   You can force GNU Make to use the simple pipe-based jobserver (perhaps if
   you are integrating with other tools or older versions of GNU Make) by
   adding the '--jobserver-style=pipe' option to the command line of the
   top-level invocation of GNU Make, or via MAKEFLAGS or GNUMAKEFLAGS.
   To detect this change search for 'jobserver-fifo' in the .FEATURES variable.


Another curious question:  Does this fifo jobserver allow .NOTPARALLEL even with 
recursive makes?  I guess not, but I had to ask.


Cheers,

Alex
--



OpenPGP_signature
Description: OpenPGP digital signature


GNU Make 4.4 released!

2022-10-31 Thread Paul Smith

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/


The next stable release of GNU make, 4.4, is available now for download:

5da8b0fcc500de9c254ca59e58558b27  make-4.4.tar.lz
d7575a26a94ee8427130e9db23cdaa78  make-4.4.tar.gz

You can obtain a copy from:   https://ftp.gnu.org/gnu/make/?C=M;O=D
You can choose a nearby mirror:   https://ftpmirror.gnu.org/make/
A list of mirror sites is available:  https://www.gnu.org/order/ftp.html

- NEWS 

Version 4.4 (31 Oct 2022)

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

https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=109=custom

* WARNING: Deprecation!
  The following systems are deprecated in this release:
- OS/2 (EMX)
- AmigaOS
- Xenix
- Cray
  In the NEXT release of GNU Make, support for these systems will be removed.
  If you want to see them continue to be supported, contact .

* WARNING: Future backward-incompatibility!
  In the NEXT release of GNU Make, pattern rules will implement the same
  behavior change for multiple targets as explicit grouped targets, below: if
  any target of the rule is needed by the build, the recipe will be invoked if
  any target of the rule is missing or out of date.  During testing some
  makefiles were found to contain pattern rules that do not build all targets;
  this can cause issues so we are delaying this change for one release cycle
  to allow these makefiles to be updated.  GNU Make shows a warning if it
  detects this situation: "pattern recipe did not update peer target".

* WARNING: Backward-incompatibility!
  GNU Make now uses temporary files in more situations than previous releases.
  If your build system sets TMPDIR (or TMP or TEMP on Windows) and deletes the
  contents during the build, or uses restrictive permissions, this may cause
  problems.  You can choose an alternative temporary directory only for use by
  GNU Make by setting the new MAKE_TMPDIR environment variable before invoking
  make.  Note that this value CANNOT be set inside the makefile, since make
  needs to find its temporary directory before the makefiles are parsed.

* WARNING: Backward-incompatibility!
  Previously each target in a explicit grouped target rule was considered
  individually: if the targets needed by the build were not out of date the
  recipe was not run even if other targets in the group were out of date.  Now
  if any of the grouped targets are needed by the build, then if any of the
  grouped targets are out of date the recipe is run and all targets in the
  group are considered updated.

* WARNING: Backward-incompatibility!
  Previously if --no-print-directory was seen anywhere in the environment or
  command line it would take precedence over any --print-directory.  Now, the
  last setting of directory printing options seen will be used, so a command
  line such as "--no-print-directory -w" _will_ show directory entry/exits.

* WARNING: Backward-incompatibility!
  Previously the order in which makefiles were remade was not explicitly
  stated, but it was (roughly) the inverse of the order in which they were
  processed by make.  In this release, the order in which makefiles are
  rebuilt is the same order in which make processed them, and this is defined
  to be true in the GNU Make manual.

* WARNING: Backward-incompatibility!
  Previously only simple (one-letter) options were added to the MAKEFLAGS
  variable that was visible while parsing makefiles.  Now, all options are
  available in MAKEFLAGS.  If you want to check MAKEFLAGS for a one-letter
  option, expanding "$(firstword -$(MAKEFLAGS))" is a reliable way to return
  the set of one-letter options which can be examined via findstring, etc.

* WARNING: Backward-incompatibility!
  Previously makefile variables marked as export were not exported to commands
  started by the $(shell ...) function.  Now, all exported variables are
  exported to $(shell ...).  If this leads to recursion during expansion, then
  for backward-compatibility the value from the original environment is used.
  To detect this change search for 'shell-export' in the .FEATURES variable.

* WARNING: New build requirement
  GNU Make utilizes facilities from GNU Gnulib: Gnulib requires certain C99
  features in the C compiler and so these features are required by GNU Make:
  https://www.gnu.org/software/gnulib/manual/html_node/C99-features-assumed.html
  The configure script should verify the compiler has these features.

* New feature: The .WAIT special target
  If the .WAIT target appears between two prerequisites of a target, then
  GNU Make will wait for all of