headers
Stefano Lattarini | 1 Nov 2011 13:12
Picon

[PATCH] m4sh: always re-exec with $CONFIG_SHELL, if it's set

* lib/m4sugar/m4sh.m4 (_AS_DETECT_BETTER_SHELL): Always re-execute
the current script with $CONFIG_SHELL, if that's set.
* tests/m4sh.at: Add tests for the new semantics, in ...
(Re-exec with CONFIG_SHELL): ... this new section.
* doc/autoconf.texi (config.status Invocation): Update.
* doc/install.texi (Defining Variables): Likewise.
* NEWS: Likewise.
---
 ChangeLog           |   11 ++++++
 doc/autoconf.texi   |   11 ++----
 doc/install.texi    |    6 ++--
 lib/m4sugar/m4sh.m4 |   90 +++++++++++++++++++++++++++++++++-----------------
 tests/m4sh.at       |   68 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 145 insertions(+), 41 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e51f7d7..188c394 100644
--- a/ChangeLog
+++ b/ChangeLog
 <at>  <at>  -1,3 +1,14  <at>  <at> 
+2011-11-01  Stefano Lattarini  <stefano.lattarini <at> gmail.com>
+
+	m4sh: always re-exec with $CONFIG_SHELL, if it's set
+	* lib/m4sugar/m4sh.m4 (_AS_DETECT_BETTER_SHELL): Always re-execute
+	the current script with $CONFIG_SHELL, if that's set.
+	* tests/m4sh.at: Add tests for the new semantics, in ...
+	(Re-exec with CONFIG_SHELL): ... this new section.
+	* doc/autoconf.texi (config.status Invocation): Update.
+	* doc/install.texi (Defining Variables): Likewise.
+	* NEWS: Likewise.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Paul Eggert | 1 Nov 2011 16:06
Favicon

Re: [PATCH] m4sh: always re-exec with $CONFIG_SHELL, if it's set

The idea behind this patch sounds good to me.
I haven't examined the detailed mechanics, though.
Permalink | Reply | 0 comments |
headers
Stefano Lattarini | 8 Nov 2011 12:02
Picon

Re: [PATCH] m4sh: always re-exec with $CONFIG_SHELL, if it's set

On Tuesday 01 November 2011, Stefano Lattarini wrote:
> * lib/m4sugar/m4sh.m4 (_AS_DETECT_BETTER_SHELL): Always re-execute
> the current script with $CONFIG_SHELL, if that's set.
> * tests/m4sh.at: Add tests for the new semantics, in ...
> (Re-exec with CONFIG_SHELL): ... this new section.
> * doc/autoconf.texi (config.status Invocation): Update.
> * doc/install.texi (Defining Variables): Likewise.
> * NEWS: Likewise.
> ---
>  ChangeLog           |   11 ++++++
>  doc/autoconf.texi   |   11 ++----
>  doc/install.texi    |    6 ++--
>  lib/m4sugar/m4sh.m4 |   90 +++++++++++++++++++++++++++++++++-----------------
>  tests/m4sh.at       |   68 ++++++++++++++++++++++++++++++++++++++
>  5 files changed, 145 insertions(+), 41 deletions(-)
> 
Ping?

BTW, I see that this patch might raise some questions, and some of its
effects can indeed be debatable; and anyway, it certainly leaves ample
room for improvement.  So I'm not asking to ACK (or NACK) it for master
right now -- maybe we could create a new public branch where to install
it (and any follow-up as well), and merge it to master only later, when
(and if) it gets consensus.

Regards,
  Stefano
Permalink | Reply | 4 comments |
headers
Paul Eggert | 8 Nov 2011 18:12
Favicon

Re: [PATCH] m4sh: always re-exec with $CONFIG_SHELL, if it's set

On 11/08/11 03:02, Stefano Lattarini wrote:
> I see that this patch might raise some questions, and some of its
> effects can indeed be debatable; and anyway, it certainly leaves ample
> room for improvement.

Could you elaborate a bit on that?
I'd rather avoid a branch if I could, and just install it,
but would like to know its effects and shortcomings first.

(Evidently nobody has had the time to review it carefully,
but if we had started a branch every time *that* had happened,
Autoconf would have thousands of branches by now. :-)
Permalink | Reply | 3 comments |
headers
Stefano Lattarini | 8 Nov 2011 20:54
Picon

Re: [PATCH] m4sh: always re-exec with $CONFIG_SHELL, if it's set

Hi Paul, thanks for the quick reply.

On Tuesday 08 November 2011, Paul Eggert wrote:
> On 11/08/11 03:02, Stefano Lattarini wrote:
> > I see that this patch might raise some questions, and some of its
> > effects can indeed be debatable; and anyway, it certainly leaves ample
> > room for improvement.
> 
> Could you elaborate a bit on that?
>
Yes (and sorry for the curtness, I'm in bit of a hurry right now):

 1. With this patch, not only configure will always re-execute itself with
    $CONFIG_SHELL when that is set (which I think is good BTW, otherwise I
    wouldn't have sent the patch ;-) --- *all* the m4sh-generated scripts
    will do the same as well.  This is probably an overkill, and might be
    undesirable under certain conditions (or simply for the tastes of some
    prospective m4sh clients).

 2. There is currently no documented way to prevent this re-execution;
    in the long run, it would be nice to offer possibility for overrides
    (the user is always right!), both "global" (with an environment
    variable probably -- CONFIG_SHELL_NO_REEXEC? or M4SH_NO_REEXEC?)
    and "local" (an ad-hoc "early" option for configure maybe, say
    `--no-reexec'?).

 3. The current implementation of _AS_DETECT_BETTER_SHELL probably does
    too much; see the "FIXME" comment my patch introduces:
     # The real workhorse for detecting a shell with the correct features.
     # FIXME: this should be split into two macros, one to detect a better
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Eggert | 9 Nov 2011 19:57
Favicon

Re: [PATCH] m4sh: always re-exec with $CONFIG_SHELL, if it's set

On 11/08/11 11:54, Stefano Lattarini wrote:
>> I'd rather avoid a branch if I could,
>> >
> Why?  That is the best way to keep the work public and going, without 
> risking to destabilize the code base.

My experience with branches in Emacs (a much more-heavily-maintained
project) is that their advantages in stability are often outweighed by
their disadvantages in maintenance overhead.  There's no real problem
if a branch is used by just one developer (as this is logically equivalent
to a private copy), nor if a set of developers works exclusively in a
branch (this is rarer, but it can work), but there is a real hassle
if stuff needs to be shared among branches.

In this particular case, if you want to create a branch that (presumably)
just you will use, and you're doing it to publish your work, that'd be OK.
(Maybe you can take over the 'experimental' branch, which
hasn't been used since 1999....)

One thing that'd be helpful is to put the four issues mentioned in your previous
message into the branch somewhere, so that other developers are reminded
of pending problems.

And thanks for looking into the problem, by the way!
Permalink | Reply | 1 comment |
headers
Stefano Lattarini | 10 Nov 2011 11:44
Picon

Re: [PATCH] m4sh: always re-exec with $CONFIG_SHELL, if it's set

On Wednesday 09 November 2011, Paul Eggert wrote:
> On 11/08/11 11:54, Stefano Lattarini wrote:
> >> I'd rather avoid a branch if I could,
> >> >
> > Why?  That is the best way to keep the work public and going, without 
> > risking to destabilize the code base.
> 
> My experience with branches in Emacs (a much more-heavily-maintained
> project) is that their advantages in stability are often outweighed by
> their disadvantages in maintenance overhead.
>
Yes, but my intention is for "my" branch to be a short-lived one (i.e.,
we will work on it, test it, polish it, and after a month or two decide
if is should be merged into master or scrapped).  The maintainance
overhead should just be temporary.

> There's no real problem if a branch is used by just one developer (as
> this is logically equivalent to a private copy), nor if a set of
> developers works exclusively in a branch (this is rarer, but it can
> work), but there is a real hassle if stuff needs to be shared among
> branches.
>
I don't see how this could be a problem here: we will just keep master
merged into the new branch, to avoid problems with synchronization and
spurious conflicts.  This is IMHO the way to proceed with independent
topic branches (like this one).  True, problems can arise if there are
different topic branches that are conflictual or subtly inter-dependent;
but this is clearly not the case here.  Also, autoconf is not being
heavily worked on at the moment, so the risk of extra churn and real
conflicts is basically zero.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bert Wesarg | 11 Nov 2011 15:03

[RFC/PATCH 3/3] autoreconf: Use note channel for enter/leave messages.

GNU Make always prints them, except when using --silent. Adopt this
behavior.

* lib/Autom4te/ChannelDefs.pm (note): New. ( <at> EXPORT): Add note.
* bin/autoreconf.in (autoreconf): Use new note sub for enter/leave
directory messages. Do not print them when no directry was given or empty.
(parse_args): Use '' in ARGV when no directory was given, so that no
enter/leave messages are printed.

Signed-off-by: Bert Wesarg <bert.wesarg <at> googlemail.com>
---
 bin/autoreconf.in           |   21 ++++++++++++++-------
 lib/Autom4te/ChannelDefs.pm |   14 +++++++++++++-
 2 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/bin/autoreconf.in b/bin/autoreconf.in
index 006b1b9..c9ef36b 100644
--- a/bin/autoreconf.in
+++ b/bin/autoreconf.in
 <at>  <at>  -172,7 +172,8  <at>  <at>  sub parse_args ()
   # is simpler, and (ii) we are still able to diagnose simultaneous
   # presence of configure.ac and configure.in.
    <at> ARGV = map { /configure\.(ac|in)$/ ? dirname ($_) : $_ }  <at> ARGV;
-  push  <at> ARGV, '.' unless  <at> ARGV;
+  # do not use '.', so that we don't print the enter/leave messages
+  push  <at> ARGV, '' unless  <at> ARGV;

   if ($verbose && $debug)
     {
 <at>  <at>  -667,17 +668,23  <at>  <at>  sub autoreconf ($)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bert Wesarg | 11 Nov 2011 15:03

[RFC/PATCH 1/3] Do not silent the note channel based on --verbose.

* lib/Autom4te/General.pm (getopt): Do not silence the note channel based
on --verbose.
* lib/Autom4te/FileUtils.pm (update_file): Use the verbose channel for
messages.
* tests/m4sugar.at: Extend expected output, because -Werror prints now
something.

Signed-off-by: Bert Wesarg <bert.wesarg <at> googlemail.com>
---
 lib/Autom4te/FileUtils.pm |    6 +++---
 lib/Autom4te/General.pm   |    1 -
 tests/m4sugar.at          |    3 ++-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/Autom4te/FileUtils.pm b/lib/Autom4te/FileUtils.pm
index 150db33..71c3791 100644
--- a/lib/Autom4te/FileUtils.pm
+++ b/lib/Autom4te/FileUtils.pm
 <at>  <at>  -182,7 +182,7  <at>  <at>  sub update_file ($$;$)
   if (!$force && -f "$to" && compare ("$from", "$to") == 0)
     {
       # File didn't change, so don't update its mod time.
-      msg 'note', "`$to' is unchanged";
+      verb "`$to' is unchanged";
       unlink ($from)
         or fatal "cannot remove $from: $!";
       return
 <at>  <at>  -195,13 +195,13  <at>  <at>  sub update_file ($$;$)
 	or fatal "cannot backup $to: $!";
       move ("$from", "$to")
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bert Wesarg | 11 Nov 2011 15:03

[RFC/PATCH 2/3] Provide --silent to silence note messages.

* lib/Autom4te/General.pm (getopt): Add --silent to standard options.
Silence note messages when --silent was given.
* bin/autoheader.in, bin/autom4te.in, bin/autoreconf.in, bin/autoscan.in
($help): Add --silent.

Signed-off-by: Bert Wesarg <bert.wesarg <at> googlemail.com>
---
 bin/autoheader.in       |    1 +
 bin/autom4te.in         |    1 +
 bin/autoreconf.in       |    1 +
 bin/autoscan.in         |    1 +
 lib/Autom4te/General.pm |    4 +++-
 5 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/bin/autoheader.in b/bin/autoheader.in
index 7086a9b..272222f 100644
--- a/bin/autoheader.in
+++ b/bin/autoheader.in
 <at>  <at>  -67,6 +67,7  <at>  <at>  or else \`configure.in\'.

   -h, --help               print this help, then exit
   -V, --version            print version number, then exit
+      --silent             silence report processing
   -v, --verbose            verbosely report processing
   -d, --debug              don\'t remove temporary files
   -f, --force              consider all files obsolete
diff --git a/bin/autom4te.in b/bin/autom4te.in
index 4ad9570..fafc7c0 100644
--- a/bin/autom4te.in
+++ b/bin/autom4te.in
(Continue reading)

Permalink | Reply | 1 comment |

Gmane