[PATCH] doc: Mention effect of 'autoreconf -fi' on INSTALL

Several projects have a bootstrap script that invokes 'autoreconf -fi' as part of a fresh version control checkout, in order to avoid storing common files in version control, while also allowing contributors to rerun bootstrap to pick up the benefits of any upgrade of one of the autotools. However

Re: [PATCH 3/3] maint: Allow amendments to git log when generating ChangeLog

[adding coreutils] On 12/22/2016 03:36 PM, Eric Blake wrote: > Copied from Coreutils. Note that git-log-fix does not yet > exist, and even when it does, it will not be part of the > tarball (since it only makes sense in the context of a git > checkout). > > * Makefile.am (gen-ChangeLog): Allow f

[PATCH 1/3] maint: Merge HACKING and README-hacking

It makes no sense to have two files that describe things that only apply to a git checkout, when only one will do. Signed-off-by: Eric Blake --- HACKING| 134 +++--- README-hacking | 139 -

[PATCH 2/3] maint: Tweak HACKING for generated ChangeLog

Signed-off-by: Eric Blake --- HACKING | 39 +-- 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/HACKING b/HACKING index 07d7bcd..0f53bb8 100644 --- a/HACKING +++ b/HACKING @@ -33,16 +33,6 @@ generate the version string. Therefore, we recommend:

[PATCH 3/3] maint: Allow amendments to git log when generating ChangeLog

Copied from Coreutils. Note that git-log-fix does not yet exist, and even when it does, it will not be part of the tarball (since it only makes sense in the context of a git checkout). * Makefile.am (gen-ChangeLog): Allow for corrections. Signed-off-by: Eric Blake --- Makefile.am | 6 +- 1

[RFC PATCH 0/3] HACKING cleanups

Inspired by the recent application of Ben's patch. I don't know if it is worth trying to omit mention of HACKING from the generated ChangeLot. gitlog-to-changelog has an --ignore-matching option that could be used to filter out all commits that are git-only (in which case I would retitle these com

Re: update HACKING file

On 11/25/2015 04:08 AM, Ben Elliston wrote: > Fairly obvious. Apologies for going more than a year without replying. > > Cheers, Ben > > --- > HACKING | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/HACKING b/HACKING > index 0005988..a894e1d 100644 > --- a/HACKING

[PATCH] doc: Patterns in m4_pattern_forbid cause error, not warning

The example text regarding a desired literal AC_DC in output claimed that the result would trigger a warning if one does not use creative quoting; but in reality, autoconf's use of m4_pattern_forbid to reserve the entire AC_ namespace makes it a hard error. Reword the section to mention the use of

[PATCH 1/2] m4sh: Add _AS_INVOCATION

When outputting a script's command line to a log file, it helps if we quote arguments suitable for re-pasting into a shell command line. Since we have more than one site (configure and config.status) that weren't doing this, it helps if we first add an m4sh primitive for easily creating this forma

[PATCH 2/2] autoconf: Properly quote logged command line

We were previously logging the wrong command line if the user invoked any argument with spaces, making it difficult to re-invoke configure with the same complex arguments. To reproduce, open any autoconf-using project and run: $ ./configure FLAGS='foo bar' >/dev/null && grep -m1 /configure config.

[PATCH 0/2] Fix logged command line

7 weeks after Kevin's report, and I finally had time to try my hand at the proposed fix for what gets logged when you do: ./configure FLAGS='foo bar' It would be nice to get a review, but I will probably include it in autoconf 2.70 (which I still hope to release next week) whether or not it has b