Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

2011-08-18 Thread Stefano Lattarini
On Tuesday 16 August 2011, Bob Friesenhahn wrote:
 On Tue, 16 Aug 2011, Stefano Lattarini wrote:
 
  What is useful information today may become 'lore' in a few years so
  it would be good to add additional data so that the reader (and
  documentation maintainer) knows the vintage of the information.
 
  That's a good point.  Do you think it would be OK to put such information
  only in Texinfo comments for the moment, and then, as a second and later
  step, devise a way to report it in the final manual too?  This second step
  wouldn't be trivial IMHO, since we would need to present such version
  information in a way that is at the same time clear, non-obtrusive and
  complete (mabe we could take a look at how Gnulib does this?).  Finally,
  as a third step, we might try to revisit the existing examples of bugs
  and portability pitfalls, and try to pin-point them to a precise version
  of the system/tools used (in case this version is not already reported).
 
 Perhaps specifying the OS release version the issue was noticed on 
 (not all-inclusive) or the date that the issue was noticed would be 
 sufficient?  For example FreeBSD 8.2 rather than FreeBSD? or 
 FreeBSD (2011) rather than FreeBSD?  The drawback of this might be 
 that someone may assume that the issues are particular to that release 
 only.
 
 Hardly anyone reads the raw Texinfo so comments in the Texinfo do not 
 seem very useful for the common reader.  If the reader knows that the 
 current version of FreeBSD is 12.8, then he might want to check to see 
 if claims made about 8.2 (totally defunct by then) are still 
 applicable. Comments in the raw Texinfo from the authors regarding 
 versions when the issue was checked (or rechecked) would be useful.
 
 Bob
 
OK, given your considerations, I've updated my patch with the attached
squash-in.  The amended patch is attached too.  Let me know if it is
good to apply now.

Regards,
  Stefano
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index b2b0a59..a0f7a55 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -19838,7 +19838,8 @@ all:
 @end example
 
 @noindent
-may output the following with @code{make -j1}:
+may output the following with @code{make -j1}, at least on NetBSD up to
+5.1 and FreeBSD up to 8.2:
 
 @example
 /
@@ -19877,17 +19878,18 @@ read:
 @c $$ @c restore font-lock
 $ @kbd{echo foo | make read}
 LINE: foo
-$ @kbd{echo foo | make -j1 read}
+$ @kbd{echo foo | make -j1 read} # NetBSD 5.1 and FreeBSD 8.2
 LINE:
 @end example
 
 @noindent
-Moreover, when FreeBSD @command{make} is run in parallel mode, it
-implements the @code{@@} and @code{-} ``recipe modifiers'' by dynamically
-modifying the active shell flags.  This behaviour has the effects of
-potentially clobbering the exit status of recipes silenced with the
-@code{@@} modifier if they also unset the @option{errexit} shell flag,
-and of mangling the output in unexpected ways:
+Moreover, when FreeBSD @command{make} (up at least to 8.2) is run in
+parallel mode, it implements the @code{@@} and @code{-} ``recipe
+modifiers'' by dynamically modifying the active shell flags.  This
+behaviour has the effects of potentially clobbering the exit status
+of recipes silenced with the @code{@@} modifier if they also unset
+the @option{errexit} shell flag, and of mangling the output in
+unexpected ways:
 
 @example
 $ @kbd{cat Makefile}
@@ -19928,12 +19930,12 @@ standard output is connected to a tty, the recipe command will not be:
 $ @kbd{cat Makefile}
 all:
 @@test -t 1  echo Is a tty || echo Is not a tty
-$ @kbd{make -j 2} # FreeBSD make
+$ @kbd{make -j 2} # FreeBSD 8.2 make
 Is not a tty
-$ @kbd{make -j 2} # NetBSD make
+$ @kbd{make -j 2} # NetBSD 5.1 make
 --- all ---
 Is not a tty
-$ @kbd{dmake -j 2} # Solaris dmake
+$ @kbd{dmake -j 2} # Solaris 10 dmake
 @var{hostname} -- 1 job
 @var{hostname} -- Job output
 Is not a tty
From a621f6fb03ee2ce45bafd882b17dafc9a8d0bdeb Mon Sep 17 00:00:00 2001
Message-Id: a621f6fb03ee2ce45bafd882b17dafc9a8d0bdeb.1313693483.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Tue, 16 Aug 2011 18:31:42 +0200
Subject: [PATCH] docs: other issues with parallel BSD make

Motivated by automake bug#9245:
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9245
and FreeBSD PR bin/159730:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=159730

* doc/autoconf.texi (Parallel Make): Document other BSD make
incompatibilities.  Reorganize the existing related documentation
accordingly.
---
 ChangeLog |   11 
 doc/autoconf.texi |  141 +++-
 2 files changed, 106 insertions(+), 46 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6ca51fd..6e36455 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2011-08-16  Stefano Lattarini  stefano.lattar...@gmail.com
+
+	docs: other issues with parallel BSD make
+	Motivated by automake bug#9245:
+	 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9245
+	and FreeBSD PR 

Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

2011-08-18 Thread Bob Friesenhahn

On Thu, 18 Aug 2011, Stefano Lattarini wrote:



OK, given your considerations, I've updated my patch with the attached
squash-in.  The amended patch is attached too.  Let me know if it is
good to apply now.


This seems much better to me.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

2011-08-18 Thread Bob Friesenhahn

On Thu, 18 Aug 2011, Stefano Lattarini wrote:



OK, given your considerations, I've updated my patch with the attached
squash-in.  The amended patch is attached too.  Let me know if it is
good to apply now.


This seems much better to me.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf


Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

2011-08-16 Thread Bob Friesenhahn

On Tue, 16 Aug 2011, Stefano Lattarini wrote:


What is useful information today may become 'lore' in a few years so
it would be good to add additional data so that the reader (and
documentation maintainer) knows the vintage of the information.


That's a good point.  Do you think it would be OK to put such information
only in Texinfo comments for the moment, and then, as a second and later
step, devise a way to report it in the final manual too?  This second step
wouldn't be trivial IMHO, since we would need to present such version
information in a way that is at the same time clear, non-obtrusive and
complete (mabe we could take a look at how Gnulib does this?).  Finally,
as a third step, we might try to revisit the existing examples of bugs
and portability pitfalls, and try to pin-point them to a precise version
of the system/tools used (in case this version is not already reported).


Perhaps specifying the OS release version the issue was noticed on 
(not all-inclusive) or the date that the issue was noticed would be 
sufficient?  For example FreeBSD 8.2 rather than FreeBSD? or 
FreeBSD (2011) rather than FreeBSD?  The drawback of this might be 
that someone may assume that the issues are particular to that release 
only.


Hardly anyone reads the raw Texinfo so comments in the Texinfo do not 
seem very useful for the common reader.  If the reader knows that the 
current version of FreeBSD is 12.8, then he might want to check to see 
if claims made about 8.2 (totally defunct by then) are still 
applicable. Comments in the raw Texinfo from the authors regarding 
versions when the issue was checked (or rechecked) would be useful.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

2011-08-16 Thread Bob Friesenhahn

On Tue, 16 Aug 2011, Stefano Lattarini wrote:



I'll have a draft patch read soonish.  There is ample room for improvements,
but I'll post it here anyway since it can benefit from early feedback.


Here it is.  As usual, comments and suggestions welcome.


The proposed documentation seems quite useful.  It does have a flaw in 
that it identifies 'make' programs based on the operating system where 
they were currently found (e.g. FreeBSD make).  The issues may 
pertain to only certain versions of such make programs, or the 'make' 
associated with an OS may be entirely supplanted (or optionally 
replaced) with a 'make' which offers completely different behavior.


What is useful information today may become 'lore' in a few years so 
it would be good to add additional data so that the reader (and 
documentation maintainer) knows the vintage of the information.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf


Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

2011-08-16 Thread Stefano Lattarini
Hi Bob.

On Tuesday 16 August 2011, Bob Friesenhahn wrote:
 On Tue, 16 Aug 2011, Stefano Lattarini wrote:
 
  I'll have a draft patch read soonish.  There is ample room for 
  improvements,
  but I'll post it here anyway since it can benefit from early feedback.
 
  Here it is.  As usual, comments and suggestions welcome.
 
 The proposed documentation seems quite useful.  It does have a flaw in 
 that it identifies 'make' programs based on the operating system where 
 they were currently found (e.g. FreeBSD make).  The issues may 
 pertain to only certain versions of such make programs, or the 'make' 
 associated with an OS may be entirely supplanted (or optionally 
 replaced) with a 'make' which offers completely different behavior.
 
 What is useful information today may become 'lore' in a few years so 
 it would be good to add additional data so that the reader (and 
 documentation maintainer) knows the vintage of the information.
 
That's a good point.  Do you think it would be OK to put such information
only in Texinfo comments for the moment, and then, as a second and later
step, devise a way to report it in the final manual too?  This second step
wouldn't be trivial IMHO, since we would need to present such version
information in a way that is at the same time clear, non-obtrusive and
complete (mabe we could take a look at how Gnulib does this?).  Finally,
as a third step, we might try to revisit the existing examples of bugs
and portability pitfalls, and try to pin-point them to a precise version
of the system/tools used (in case this version is not already reported).

Regards,
  Stefano

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf


Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

2011-08-16 Thread Bob Friesenhahn

On Tue, 16 Aug 2011, Stefano Lattarini wrote:


What is useful information today may become 'lore' in a few years so
it would be good to add additional data so that the reader (and
documentation maintainer) knows the vintage of the information.


That's a good point.  Do you think it would be OK to put such information
only in Texinfo comments for the moment, and then, as a second and later
step, devise a way to report it in the final manual too?  This second step
wouldn't be trivial IMHO, since we would need to present such version
information in a way that is at the same time clear, non-obtrusive and
complete (mabe we could take a look at how Gnulib does this?).  Finally,
as a third step, we might try to revisit the existing examples of bugs
and portability pitfalls, and try to pin-point them to a precise version
of the system/tools used (in case this version is not already reported).


Perhaps specifying the OS release version the issue was noticed on 
(not all-inclusive) or the date that the issue was noticed would be 
sufficient?  For example FreeBSD 8.2 rather than FreeBSD? or 
FreeBSD (2011) rather than FreeBSD?  The drawback of this might be 
that someone may assume that the issues are particular to that release 
only.


Hardly anyone reads the raw Texinfo so comments in the Texinfo do not 
seem very useful for the common reader.  If the reader knows that the 
current version of FreeBSD is 12.8, then he might want to check to see 
if claims made about 8.2 (totally defunct by then) are still 
applicable. Comments in the raw Texinfo from the authors regarding 
versions when the issue was checked (or rechecked) would be useful.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf