* [PATCH 1/3] src-release: fix indentation
@ 2021-01-10 3:37 Mike Frysinger
2021-01-10 3:37 ` [PATCH 2/3] gnulib: import gitlog-to-changelog Mike Frysinger
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Mike Frysinger @ 2021-01-10 3:37 UTC (permalink / raw)
To: gdb-patches
The indentation of the body of the nested statements got out of sync
leading to the entire function being indented incorrectly and looking
like it's part of the for loop.
* src-release.sh (do_proto_toplev): Rewrite indentation.
---
src-release.sh | 68 ++++++++++++++++++++++++--------------------------
1 file changed, 33 insertions(+), 35 deletions(-)
diff --git a/src-release.sh b/src-release.sh
index fd65856a55cc..d24a63c99b0a 100755
--- a/src-release.sh
+++ b/src-release.sh
@@ -126,44 +126,42 @@ do_proto_toplev()
fi
else
if (echo x$d | grep / >/dev/null); then
- mkdir -p proto-toplev/`dirname $d`
- x=`dirname $d`
- ln -s ../`echo $x/ | sed -e 's,[^/]*/,../,g'`$d proto-toplev/$d
+ mkdir -p proto-toplev/`dirname $d`
+ x=`dirname $d`
+ ln -s ../`echo $x/ | sed -e 's,[^/]*/,../,g'`$d proto-toplev/$d
else
- ln -s ../$d proto-toplev/$d
+ ln -s ../$d proto-toplev/$d
fi
- fi
- done
- (cd etc; $MAKE MAKEINFOFLAGS="$MAKEINFOFLAGS" info)
- $MAKE distclean
- mkdir proto-toplev/etc
- (cd proto-toplev/etc;
- for i in $ETC_SUPPORT; do
- ln -s ../../etc/$i .
- done)
- #
- # Take out texinfo from configurable dirs
- rm proto-toplev/configure.ac
- sed -e '/^host_tools=/s/texinfo //' \
- <configure.ac >proto-toplev/configure.ac
- #
- mkdir proto-toplev/texinfo
- ln -s ../../texinfo/texinfo.tex proto-toplev/texinfo/
- if test -r texinfo/util/tex3patch ; then
- mkdir proto-toplev/texinfo/util && \
- ln -s ../../../texinfo/util/tex3patch proto-toplev/texinfo/util
- else
- true
fi
- chmod -R og=u . || chmod og=u `find . -print`
- #
- # Create .gmo files from .po files.
- for f in `find . -name '*.po' -type f -print`; do
- msgfmt -o `echo $f | sed -e 's/\.po$/.gmo/'` $f
- done
- #
- rm -f $package-$ver
- ln -s proto-toplev $package-$ver
+ done
+ (cd etc; $MAKE MAKEINFOFLAGS="$MAKEINFOFLAGS" info)
+ $MAKE distclean
+ mkdir proto-toplev/etc
+ (cd proto-toplev/etc;
+ for i in $ETC_SUPPORT; do
+ ln -s ../../etc/$i .
+ done)
+ #
+ # Take out texinfo from configurable dirs
+ rm proto-toplev/configure.ac
+ sed -e '/^host_tools=/s/texinfo //' \
+ <configure.ac >proto-toplev/configure.ac
+ #
+ mkdir proto-toplev/texinfo
+ ln -s ../../texinfo/texinfo.tex proto-toplev/texinfo/
+ if test -r texinfo/util/tex3patch ; then
+ mkdir proto-toplev/texinfo/util && \
+ ln -s ../../../texinfo/util/tex3patch proto-toplev/texinfo/util
+ fi
+ chmod -R og=u . || chmod og=u `find . -print`
+ #
+ # Create .gmo files from .po files.
+ for f in `find . -name '*.po' -type f -print`; do
+ msgfmt -o `echo $f | sed -e 's/\.po$/.gmo/'` $f
+ done
+ #
+ rm -f $package-$ver
+ ln -s proto-toplev $package-$ver
}
CVS_NAMES='-name CVS -o -name .cvsignore'
--
2.28.0
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 2/3] gnulib: import gitlog-to-changelog
2021-01-10 3:37 [PATCH 1/3] src-release: fix indentation Mike Frysinger
@ 2021-01-10 3:37 ` Mike Frysinger
2021-01-11 11:06 ` Andrew Burgess
2021-01-10 3:42 ` [PATCH] sim: switch to autogenerated ChangeLog files Mike Frysinger
2021-01-12 23:20 ` [PATCH 1/3] src-release: fix indentation Mike Frysinger
2 siblings, 1 reply; 21+ messages in thread
From: Mike Frysinger @ 2021-01-10 3:37 UTC (permalink / raw)
To: gdb-patches
This is going to be used to generate ChangeLog files.
gnulib/:
* update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add gitlog-to-changelog.
* Makefile.in, configure: Regenerate.
* import/Makefile.am, import/Makefile.in: Regenerate.
* import/m4/gnulib-cache.m4: Regenerate.
* import/m4/gnulib-comp.m4: Regenerate.
* import/extra/gitlog-to-changelog: New file.
---
gnulib/Makefile.in | 2 +-
gnulib/configure | 1 +
gnulib/import/Makefile.am | 8 +
gnulib/import/Makefile.in | 14 +-
| 515 ++++++++++++++++++++++++
gnulib/import/m4/gnulib-cache.m4 | 2 +
gnulib/import/m4/gnulib-comp.m4 | 2 +
gnulib/update-gnulib.sh | 1 +
8 files changed, 538 insertions(+), 7 deletions(-)
create mode 100755 gnulib/import/extra/gitlog-to-changelog
diff --git a/gnulib/Makefile.in b/gnulib/Makefile.in
index c1c216809446..69161b1f7ed5 100644
--- a/gnulib/Makefile.in
+++ b/gnulib/Makefile.in
@@ -14,7 +14,7 @@
@SET_MAKE@
-# Copyright (C) 2019-2020 Free Software Foundation, Inc.
+# Copyright (C) 2019-2021 Free Software Foundation, Inc.
# This file is part of GDB.
diff --git a/gnulib/configure b/gnulib/configure
index 6c58a46e42ed..e4191103af58 100644
--- a/gnulib/configure
+++ b/gnulib/configure
@@ -6608,6 +6608,7 @@ fi
# Code from module getrandom:
# Code from module gettext-h:
# Code from module gettimeofday:
+ # Code from module gitlog-to-changelog:
# Code from module glob:
# Code from module glob-h:
# Code from module hard-locale:
diff --git a/gnulib/import/Makefile.am b/gnulib/import/Makefile.am
index 84de424a1734..48a642febdcc 100644
--- a/gnulib/import/Makefile.am
+++ b/gnulib/import/Makefile.am
@@ -43,6 +43,7 @@
# frexpl \
# getcwd \
# gettimeofday \
+# gitlog-to-changelog \
# glob \
# inet_ntop \
# inttypes \
@@ -703,6 +704,13 @@ EXTRA_libgnu_a_SOURCES += gettimeofday.c
## end gnulib module gettimeofday
+## begin gnulib module gitlog-to-changelog
+
+
+EXTRA_DIST += $(top_srcdir)/import/extra/gitlog-to-changelog
+
+## end gnulib module gitlog-to-changelog
+
## begin gnulib module glob
diff --git a/gnulib/import/Makefile.in b/gnulib/import/Makefile.in
index 476cde8dd57e..7c61a29499af 100644
--- a/gnulib/import/Makefile.in
+++ b/gnulib/import/Makefile.in
@@ -57,6 +57,7 @@
# frexpl \
# getcwd \
# gettimeofday \
+# gitlog-to-changelog \
# glob \
# inet_ntop \
# inttypes \
@@ -1689,12 +1690,13 @@ EXTRA_DIST = m4/gnulib-cache.m4 alloca.c alloca.in.h arpa_inet.in.h \
fnmatch.c fnmatch_loop.c fnmatch.in.h fpucw.h frexp.c frexp.c \
frexpl.c fstat.c stat-w32.c stat-w32.h at-func.c fstatat.c \
getcwd.c getcwd-lgpl.c getdtablesize.c getlogin_r.c \
- getrandom.c gettimeofday.c glob.c glob_internal.h \
- glob_pattern_p.c globfree.c glob-libc.h glob.in.h \
- hard-locale.h inet_ntop.c intprops.h inttypes.in.h isblank.c \
- float+.h isnan.c isnand-nolibm.h isnand.c float+.h isnan.c \
- isnanl-nolibm.h isnanl.c cdefs.h libc-config.h limits.in.h \
- localcharset.h locale.in.h localtime-buffer.c \
+ getrandom.c gettimeofday.c \
+ $(top_srcdir)/import/extra/gitlog-to-changelog glob.c \
+ glob_internal.h glob_pattern_p.c globfree.c glob-libc.h \
+ glob.in.h hard-locale.h inet_ntop.c intprops.h inttypes.in.h \
+ isblank.c float+.h isnan.c isnand-nolibm.h isnand.c float+.h \
+ isnan.c isnanl-nolibm.h isnanl.c cdefs.h libc-config.h \
+ limits.in.h localcharset.h locale.in.h localtime-buffer.c \
localtime-buffer.h lstat.c malloc.c malloca.h math.in.h \
lc-charset-dispatch.c lc-charset-dispatch.h \
mbrtowc-impl-utf8.h mbrtowc-impl.h mbrtowc.c mbtowc-lock.c \
--git a/gnulib/import/extra/gitlog-to-changelog b/gnulib/import/extra/gitlog-to-changelog
new file mode 100755
index 000000000000..be8082e7ffd9
--- /dev/null
+++ b/gnulib/import/extra/gitlog-to-changelog
@@ -0,0 +1,515 @@
+#!/bin/sh
+#! -*-perl-*-
+
+# Convert git log output to ChangeLog format.
+
+# Copyright (C) 2008-2020 Free Software Foundation, Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <https://www.gnu.org/licenses/>.
+#
+# Written by Jim Meyering
+
+# This is a prologue that allows to run a perl script as an executable
+# on systems that are compliant to a POSIX version before POSIX:2017.
+# On such systems, the usual invocation of an executable through execlp()
+# or execvp() fails with ENOEXEC if it is a script that does not start
+# with a #! line. The script interpreter mentioned in the #! line has
+# to be /bin/sh, because on GuixSD systems that is the only program that
+# has a fixed file name. The second line is essential for perl and is
+# also useful for editing this file in Emacs. The next two lines below
+# are valid code in both sh and perl. When executed by sh, they re-execute
+# the script through the perl program found in $PATH. The '-x' option
+# is essential as well; without it, perl would re-execute the script
+# through /bin/sh. When executed by perl, the next two lines are a no-op.
+eval 'exec perl -wSx "$0" "$@"'
+ if 0;
+
+my $VERSION = '2020-04-04 15:07'; # UTC
+# The definition above must lie within the first 8 lines in order
+# for the Emacs time-stamp write hook (at end) to update it.
+# If you change this file with Emacs, please let the write hook
+# do its job. Otherwise, update this string manually.
+
+use strict;
+use warnings;
+use Getopt::Long;
+use POSIX qw(strftime);
+
+(my $ME = $0) =~ s|.*/||;
+
+# use File::Coda; # https://meyering.net/code/Coda/
+END {
+ defined fileno STDOUT or return;
+ close STDOUT and return;
+ warn "$ME: failed to close standard output: $!\n";
+ $? ||= 1;
+}
+
+sub usage ($)
+{
+ my ($exit_code) = @_;
+ my $STREAM = ($exit_code == 0 ? *STDOUT : *STDERR);
+ if ($exit_code != 0)
+ {
+ print $STREAM "Try '$ME --help' for more information.\n";
+ }
+ else
+ {
+ print $STREAM <<EOF;
+Usage: $ME [OPTIONS] [ARGS]
+
+Convert git log output to ChangeLog format. If present, any ARGS
+are passed to "git log". To avoid ARGS being parsed as options to
+$ME, they may be preceded by '--'.
+
+OPTIONS:
+
+ --amend=FILE FILE maps from an SHA1 to perl code (i.e., s/old/new/) that
+ makes a change to SHA1's commit log text or metadata.
+ --append-dot append a dot to the first line of each commit message if
+ there is no other punctuation or blank at the end.
+ --no-cluster never cluster commit messages under the same date/author
+ header; the default is to cluster adjacent commit messages
+ if their headers are the same and neither commit message
+ contains multiple paragraphs.
+ --srcdir=DIR the root of the source tree, from which the .git/
+ directory can be derived.
+ --since=DATE convert only the logs since DATE;
+ the default is to convert all log entries.
+ --until=DATE convert only the logs older than DATE.
+ --ignore-matching=PAT ignore commit messages whose first lines match PAT.
+ --ignore-line=PAT ignore lines of commit messages that match PAT.
+ --format=FMT set format string for commit subject and body;
+ see 'man git-log' for the list of format metacharacters;
+ the default is '%s%n%b%n'
+ --strip-tab remove one additional leading TAB from commit message lines.
+ --strip-cherry-pick remove data inserted by "git cherry-pick";
+ this includes the "cherry picked from commit ..." line,
+ and the possible final "Conflicts:" paragraph.
+ --help display this help and exit
+ --version output version information and exit
+
+EXAMPLE:
+
+ $ME --since=2008-01-01 > ChangeLog
+ $ME -- -n 5 foo > last-5-commits-to-branch-foo
+
+SPECIAL SYNTAX:
+
+The following types of strings are interpreted specially when they appear
+at the beginning of a log message line. They are not copied to the output.
+
+ Copyright-paperwork-exempt: Yes
+ Append the "(tiny change)" notation to the usual "date name email"
+ ChangeLog header to mark a change that does not require a copyright
+ assignment.
+ Co-authored-by: Joe User <user\@example.com>
+ List the specified name and email address on a second
+ ChangeLog header, denoting a co-author.
+ Signed-off-by: Joe User <user\@example.com>
+ These lines are simply elided.
+
+In a FILE specified via --amend, comment lines (starting with "#") are ignored.
+FILE must consist of <SHA,CODE+> pairs where SHA is a 40-byte SHA1 (alone on
+a line) referring to a commit in the current project, and CODE refers to one
+or more consecutive lines of Perl code. Pairs must be separated by one or
+more blank line.
+
+Here is sample input for use with --amend=FILE, from coreutils:
+
+3a169f4c5d9159283548178668d2fae6fced3030
+# fix typo in title:
+s/all tile types/all file types/
+
+1379ed974f1fa39b12e2ffab18b3f7a607082202
+# Due to a bug in vc-dwim, I mis-attributed a patch by Paul to myself.
+# Change the author to be Paul. Note the escaped "@":
+s,Jim .*>,Paul Eggert <eggert\\\@cs.ucla.edu>,
+
+EOF
+ }
+ exit $exit_code;
+}
+
+# If the string $S is a well-behaved file name, simply return it.
+# If it contains white space, quotes, etc., quote it, and return the new string.
+sub shell_quote($)
+{
+ my ($s) = @_;
+ if ($s =~ m![^\w+/.,-]!)
+ {
+ # Convert each single quote to '\''
+ $s =~ s/\'/\'\\\'\'/g;
+ # Then single quote the string.
+ $s = "'$s'";
+ }
+ return $s;
+}
+
+sub quoted_cmd(@)
+{
+ return join (' ', map {shell_quote $_} @_);
+}
+
+# Parse file F.
+# Comment lines (starting with "#") are ignored.
+# F must consist of <SHA,CODE+> pairs where SHA is a 40-byte SHA1
+# (alone on a line) referring to a commit in the current project, and
+# CODE refers to one or more consecutive lines of Perl code.
+# Pairs must be separated by one or more blank line.
+sub parse_amend_file($)
+{
+ my ($f) = @_;
+
+ open F, '<', $f
+ or die "$ME: $f: failed to open for reading: $!\n";
+
+ my $fail;
+ my $h = {};
+ my $in_code = 0;
+ my $sha;
+ while (defined (my $line = <F>))
+ {
+ $line =~ /^\#/
+ and next;
+ chomp $line;
+ $line eq ''
+ and $in_code = 0, next;
+
+ if (!$in_code)
+ {
+ $line =~ /^([[:xdigit:]]{40})$/
+ or (warn "$ME: $f:$.: invalid line; expected an SHA1\n"),
+ $fail = 1, next;
+ $sha = lc $1;
+ $in_code = 1;
+ exists $h->{$sha}
+ and (warn "$ME: $f:$.: duplicate SHA1\n"),
+ $fail = 1, next;
+ }
+ else
+ {
+ $h->{$sha} ||= '';
+ $h->{$sha} .= "$line\n";
+ }
+ }
+ close F;
+
+ $fail
+ and exit 1;
+
+ return $h;
+}
+
+# git_dir_option $SRCDIR
+#
+# From $SRCDIR, the --git-dir option to pass to git (none if $SRCDIR
+# is undef). Return as a list (0 or 1 element).
+sub git_dir_option($)
+{
+ my ($srcdir) = @_;
+ my @res = ();
+ if (defined $srcdir)
+ {
+ my $qdir = shell_quote $srcdir;
+ my $cmd = "cd $qdir && git rev-parse --show-toplevel";
+ my $qcmd = shell_quote $cmd;
+ my $git_dir = qx($cmd);
+ defined $git_dir
+ or die "$ME: cannot run $qcmd: $!\n";
+ $? == 0
+ or die "$ME: $qcmd had unexpected exit code or signal ($?)\n";
+ chomp $git_dir;
+ push @res, "--git-dir=$git_dir/.git";
+ }
+ @res;
+}
+
+{
+ my $since_date;
+ my $until_date;
+ my $format_string = '%s%n%b%n';
+ my $amend_file;
+ my $append_dot = 0;
+ my $cluster = 1;
+ my $ignore_matching;
+ my $ignore_line;
+ my $strip_tab = 0;
+ my $strip_cherry_pick = 0;
+ my $srcdir;
+ GetOptions
+ (
+ help => sub { usage 0 },
+ version => sub { print "$ME version $VERSION\n"; exit },
+ 'since=s' => \$since_date,
+ 'until=s' => \$until_date,
+ 'format=s' => \$format_string,
+ 'amend=s' => \$amend_file,
+ 'append-dot' => \$append_dot,
+ 'cluster!' => \$cluster,
+ 'ignore-matching=s' => \$ignore_matching,
+ 'ignore-line=s' => \$ignore_line,
+ 'strip-tab' => \$strip_tab,
+ 'strip-cherry-pick' => \$strip_cherry_pick,
+ 'srcdir=s' => \$srcdir,
+ ) or usage 1;
+
+ defined $since_date
+ and unshift @ARGV, "--since=$since_date";
+ defined $until_date
+ and unshift @ARGV, "--until=$until_date";
+
+ # This is a hash that maps an SHA1 to perl code (i.e., s/old/new/)
+ # that makes a correction in the log or attribution of that commit.
+ my $amend_code = defined $amend_file ? parse_amend_file $amend_file : {};
+
+ my @cmd = ('git',
+ git_dir_option $srcdir,
+ qw(log --log-size),
+ '--pretty=format:%H:%ct %an <%ae>%n%n'.$format_string, @ARGV);
+ open PIPE, '-|', @cmd
+ or die ("$ME: failed to run '". quoted_cmd (@cmd) ."': $!\n"
+ . "(Is your Git too old? Version 1.5.1 or later is required.)\n");
+
+ my $prev_multi_paragraph;
+ my $prev_date_line = '';
+ my @prev_coauthors = ();
+ my @skipshas = ();
+ while (1)
+ {
+ defined (my $in = <PIPE>)
+ or last;
+ $in =~ /^log size (\d+)$/
+ or die "$ME:$.: Invalid line (expected log size):\n$in";
+ my $log_nbytes = $1;
+
+ my $log;
+ my $n_read = read PIPE, $log, $log_nbytes;
+ $n_read == $log_nbytes
+ or die "$ME:$.: unexpected EOF\n";
+
+ # Extract leading hash.
+ my ($sha, $rest) = split ':', $log, 2;
+ defined $sha
+ or die "$ME:$.: malformed log entry\n";
+ $sha =~ /^[[:xdigit:]]{40}$/
+ or die "$ME:$.: invalid SHA1: $sha\n";
+
+ my $skipflag = 0;
+ if (@skipshas)
+ {
+ foreach(@skipshas)
+ {
+ if ($sha =~ /^$_/)
+ {
+ $skipflag = $_;
+ last;
+ }
+ }
+ }
+
+ # If this commit's log requires any transformation, do it now.
+ my $code = $amend_code->{$sha};
+ if (defined $code)
+ {
+ eval 'use Safe';
+ my $s = new Safe;
+ # Put the unpreprocessed entry into "$_".
+ $_ = $rest;
+
+ # Let $code operate on it, safely.
+ my $r = $s->reval("$code")
+ or die "$ME:$.:$sha: failed to eval \"$code\":\n$@\n";
+
+ # Note that we've used this entry.
+ delete $amend_code->{$sha};
+
+ # Update $rest upon success.
+ $rest = $_;
+ }
+
+ # Remove lines inserted by "git cherry-pick".
+ if ($strip_cherry_pick)
+ {
+ $rest =~ s/^\s*Conflicts:\n.*//sm;
+ $rest =~ s/^\s*\(cherry picked from commit [\da-f]+\)\n//m;
+ }
+
+ my @line = split /[ \t]*\n/, $rest;
+ my $author_line = shift @line;
+ defined $author_line
+ or die "$ME:$.: unexpected EOF\n";
+ $author_line =~ /^(\d+) (.*>)$/
+ or die "$ME:$.: Invalid line "
+ . "(expected date/author/email):\n$author_line\n";
+
+ # Format 'Copyright-paperwork-exempt: Yes' as a standard ChangeLog
+ # `(tiny change)' annotation.
+ my $tiny = (grep (/^(?:Copyright-paperwork-exempt|Tiny-change):\s+[Yy]es$/, @line)
+ ? ' (tiny change)' : '');
+
+ my $date_line = sprintf "%s %s$tiny\n",
+ strftime ("%Y-%m-%d", localtime ($1)), $2;
+
+ my @coauthors = grep /^Co-authored-by:.*$/, @line;
+ # Omit meta-data lines we've already interpreted.
+ @line = grep !/^(?:Signed-off-by:[ ].*>$
+ |Co-authored-by:[ ]
+ |Copyright-paperwork-exempt:[ ]
+ |Tiny-change:[ ]
+ )/x, @line;
+
+ # Remove leading and trailing blank lines.
+ if (@line)
+ {
+ while ($line[0] =~ /^\s*$/) { shift @line; }
+ while ($line[$#line] =~ /^\s*$/) { pop @line; }
+ }
+
+ # Handle Emacs gitmerge.el "skipped" commits.
+ # Yes, this should be controlled by an option. So sue me.
+ if ( grep /^(; )?Merge from /, @line )
+ {
+ my $found = 0;
+ foreach (@line)
+ {
+ if (grep /^The following commit.*skipped:$/, $_)
+ {
+ $found = 1;
+ ## Reset at each merge to reduce chance of false matches.
+ @skipshas = ();
+ next;
+ }
+ if ($found && $_ =~ /^([[:xdigit:]]{7,}) [^ ]/)
+ {
+ push ( @skipshas, $1 );
+ }
+ }
+ }
+
+ # Ignore commits that match the --ignore-matching pattern, if specified.
+ if (defined $ignore_matching && @line && $line[0] =~ /$ignore_matching/)
+ {
+ $skipflag = 1;
+ }
+ elsif ($skipflag)
+ {
+ ## Perhaps only warn if a pattern matches more than once?
+ warn "$ME: warning: skipping $sha due to $skipflag\n";
+ }
+
+ if (! $skipflag)
+ {
+ if (defined $ignore_line && @line)
+ {
+ @line = grep ! /$ignore_line/, @line;
+ while ($line[$#line] =~ /^\s*$/) { pop @line; }
+ }
+
+ # Record whether there are two or more paragraphs.
+ my $multi_paragraph = grep /^\s*$/, @line;
+
+ # Format 'Co-authored-by: A U Thor <email@example.com>' lines in
+ # standard multi-author ChangeLog format.
+ for (@coauthors)
+ {
+ s/^Co-authored-by:\s*/\t /;
+ s/\s*</ </;
+
+ /<.*?@.*\..*>/
+ or warn "$ME: warning: missing email address for "
+ . substr ($_, 5) . "\n";
+ }
+
+ # If clustering of commit messages has been disabled, if this header
+ # would be different from the previous date/name/etc. header,
+ # or if this or the previous entry consists of two or more paragraphs,
+ # then print the header.
+ if ( ! $cluster
+ || $date_line ne $prev_date_line
+ || "@coauthors" ne "@prev_coauthors"
+ || $multi_paragraph
+ || $prev_multi_paragraph)
+ {
+ $prev_date_line eq ''
+ or print "\n";
+ print $date_line;
+ @coauthors
+ and print join ("\n", @coauthors), "\n";
+ }
+ $prev_date_line = $date_line;
+ @prev_coauthors = @coauthors;
+ $prev_multi_paragraph = $multi_paragraph;
+
+ # If there were any lines
+ if (@line == 0)
+ {
+ warn "$ME: warning: empty commit message:\n $date_line\n";
+ }
+ else
+ {
+ if ($append_dot)
+ {
+ # If the first line of the message has enough room, then
+ if (length $line[0] < 72)
+ {
+ # append a dot if there is no other punctuation or blank
+ # at the end.
+ $line[0] =~ /[[:punct:]\s]$/
+ or $line[0] .= '.';
+ }
+ }
+
+ # Remove one additional leading TAB from each line.
+ $strip_tab
+ and map { s/^\t// } @line;
+
+ # Prefix each non-empty line with a TAB.
+ @line = map { length $_ ? "\t$_" : '' } @line;
+
+ print "\n", join ("\n", @line), "\n";
+ }
+ }
+
+ defined ($in = <PIPE>)
+ or last;
+ $in ne "\n"
+ and die "$ME:$.: unexpected line:\n$in";
+ }
+
+ close PIPE
+ or die "$ME: error closing pipe from " . quoted_cmd (@cmd) . "\n";
+ # FIXME-someday: include $PROCESS_STATUS in the diagnostic
+
+ # Complain about any unused entry in the --amend=F specified file.
+ my $fail = 0;
+ foreach my $sha (keys %$amend_code)
+ {
+ warn "$ME:$amend_file: unused entry: $sha\n";
+ $fail = 1;
+ }
+
+ exit $fail;
+}
+
+# Local Variables:
+# mode: perl
+# indent-tabs-mode: nil
+# eval: (add-hook 'before-save-hook 'time-stamp)
+# time-stamp-line-limit: 50
+# time-stamp-start: "my $VERSION = '"
+# time-stamp-format: "%:y-%02m-%02d %02H:%02M"
+# time-stamp-time-zone: "UTC0"
+# time-stamp-end: "'; # UTC"
+# End:
diff --git a/gnulib/import/m4/gnulib-cache.m4 b/gnulib/import/m4/gnulib-cache.m4
index db95504cc6ad..c0b6d4119466 100644
--- a/gnulib/import/m4/gnulib-cache.m4
+++ b/gnulib/import/m4/gnulib-cache.m4
@@ -48,6 +48,7 @@
# frexpl \
# getcwd \
# gettimeofday \
+# gitlog-to-changelog \
# glob \
# inet_ntop \
# inttypes \
@@ -89,6 +90,7 @@ gl_MODULES([
frexpl
getcwd
gettimeofday
+ gitlog-to-changelog
glob
inet_ntop
inttypes
diff --git a/gnulib/import/m4/gnulib-comp.m4 b/gnulib/import/m4/gnulib-comp.m4
index 8c2c28ec932f..61d60db35954 100644
--- a/gnulib/import/m4/gnulib-comp.m4
+++ b/gnulib/import/m4/gnulib-comp.m4
@@ -103,6 +103,7 @@ AC_DEFUN([gl_EARLY],
# Code from module getrandom:
# Code from module gettext-h:
# Code from module gettimeofday:
+ # Code from module gitlog-to-changelog:
# Code from module glob:
# Code from module glob-h:
# Code from module hard-locale:
@@ -907,6 +908,7 @@ AC_DEFUN([gltests_LIBSOURCES], [
# This macro records the list of files which have been installed by
# gnulib-tool and may be removed by future gnulib-tool invocations.
AC_DEFUN([gl_FILE_LIST], [
+ build-aux/gitlog-to-changelog
build-aux/update-copyright
lib/_Noreturn.h
lib/alloca.c
diff --git a/gnulib/update-gnulib.sh b/gnulib/update-gnulib.sh
index e9b377ca4759..4820277e5fa9 100755
--- a/gnulib/update-gnulib.sh
+++ b/gnulib/update-gnulib.sh
@@ -40,6 +40,7 @@ IMPORTED_GNULIB_MODULES="\
frexpl \
getcwd \
gettimeofday \
+ gitlog-to-changelog \
glob \
inet_ntop
inttypes \
--
2.28.0
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-10 3:37 [PATCH 1/3] src-release: fix indentation Mike Frysinger
2021-01-10 3:37 ` [PATCH 2/3] gnulib: import gitlog-to-changelog Mike Frysinger
@ 2021-01-10 3:42 ` Mike Frysinger
2021-01-11 11:05 ` Andrew Burgess
2021-01-12 23:20 ` [PATCH 1/3] src-release: fix indentation Mike Frysinger
2 siblings, 1 reply; 21+ messages in thread
From: Mike Frysinger @ 2021-01-10 3:42 UTC (permalink / raw)
To: gdb-patches
Use the gitlog-to-changelog gnulib script to automatically generate
the ChangeLog file for the sim project in releases. This allows us
to drop the manually curated ones.
* src-release.sh (do_proto_toplev): Call gitlog-to-changelog when
$d is sim.
---
sim/ChangeLog | 1387 -----
sim/aarch64/ChangeLog | 480 --
sim/arm/ChangeLog | 1829 ------
sim/avr/ChangeLog | 315 --
sim/bfin/ChangeLog | 1205 ----
sim/bpf/ChangeLog | 62 -
sim/common/ChangeLog | 7245 ------------------------
sim/cr16/ChangeLog | 504 --
sim/cris/ChangeLog | 754 ---
sim/d10v/ChangeLog | 1756 ------
sim/erc32/ChangeLog | 1125 ----
sim/frv/ChangeLog | 3025 ----------
sim/ft32/ChangeLog | 189 -
sim/h8300/ChangeLog | 1280 -----
sim/igen/ChangeLog | 1272 -----
sim/iq2000/ChangeLog | 577 --
sim/lm32/ChangeLog | 387 --
sim/m32c/ChangeLog | 428 --
sim/m32r/ChangeLog | 2002 -------
sim/m68hc11/ChangeLog | 1030 ----
sim/mcore/ChangeLog | 578 --
sim/microblaze/ChangeLog | 350 --
sim/mips/ChangeLog | 3814 -------------
sim/mn10300/ChangeLog | 1562 -----
sim/moxie/ChangeLog | 543 --
sim/msp430/ChangeLog | 339 --
sim/or1k/ChangeLog | 60 -
sim/ppc/ChangeLog | 4296 --------------
sim/ppc/ChangeLog.00 | 2168 -------
sim/pru/ChangeLog | 38 -
sim/rl78/ChangeLog | 185 -
sim/rx/ChangeLog | 395 --
sim/sh/ChangeLog | 1662 ------
sim/testsuite/ChangeLog | 371 --
sim/testsuite/d10v-elf/ChangeLog | 139 -
sim/testsuite/frv-elf/ChangeLog | 48 -
sim/testsuite/m32r-elf/ChangeLog | 18 -
sim/testsuite/mips64el-elf/ChangeLog | 19 -
sim/testsuite/sim/aarch64/ChangeLog | 83 -
sim/testsuite/sim/arm/ChangeLog | 122 -
sim/testsuite/sim/avr/ChangeLog | 7 -
sim/testsuite/sim/bfin/ChangeLog | 370 --
sim/testsuite/sim/bpf/ChangeLog | 20 -
sim/testsuite/sim/cr16/ChangeLog | 51 -
sim/testsuite/sim/cris/ChangeLog | 197 -
sim/testsuite/sim/frv/ChangeLog | 76 -
sim/testsuite/sim/ft32/ChangeLog | 8 -
sim/testsuite/sim/h8300/ChangeLog | 107 -
sim/testsuite/sim/iq2000/ChangeLog | 3 -
sim/testsuite/sim/lm32/ChangeLog | 3 -
sim/testsuite/sim/m32c/ChangeLog | 10 -
sim/testsuite/sim/m32r/ChangeLog | 122 -
sim/testsuite/sim/m68hc11/ChangeLog | 3 -
sim/testsuite/sim/mcore/ChangeLog | 8 -
sim/testsuite/sim/microblaze/ChangeLog | 3 -
sim/testsuite/sim/mips/ChangeLog | 118 -
sim/testsuite/sim/mn10300/ChangeLog | 3 -
sim/testsuite/sim/moxie/ChangeLog | 3 -
sim/testsuite/sim/msp430/ChangeLog | 17 -
sim/testsuite/sim/or1k/ChangeLog | 46 -
sim/testsuite/sim/pru/ChangeLog | 17 -
sim/testsuite/sim/sh/ChangeLog | 77 -
sim/testsuite/sim/v850/ChangeLog | 19 -
sim/v850/ChangeLog | 1695 ------
src-release.sh | 6 +
65 files changed, 6 insertions(+), 46625 deletions(-)
delete mode 100644 sim/ChangeLog
delete mode 100644 sim/aarch64/ChangeLog
delete mode 100644 sim/arm/ChangeLog
delete mode 100644 sim/avr/ChangeLog
delete mode 100644 sim/bfin/ChangeLog
delete mode 100644 sim/bpf/ChangeLog
delete mode 100644 sim/common/ChangeLog
delete mode 100644 sim/cr16/ChangeLog
delete mode 100644 sim/cris/ChangeLog
delete mode 100644 sim/d10v/ChangeLog
delete mode 100644 sim/erc32/ChangeLog
delete mode 100644 sim/frv/ChangeLog
delete mode 100644 sim/ft32/ChangeLog
delete mode 100644 sim/h8300/ChangeLog
delete mode 100644 sim/igen/ChangeLog
delete mode 100644 sim/iq2000/ChangeLog
delete mode 100644 sim/lm32/ChangeLog
delete mode 100644 sim/m32c/ChangeLog
delete mode 100644 sim/m32r/ChangeLog
delete mode 100644 sim/m68hc11/ChangeLog
delete mode 100644 sim/mcore/ChangeLog
delete mode 100644 sim/microblaze/ChangeLog
delete mode 100644 sim/mips/ChangeLog
delete mode 100644 sim/mn10300/ChangeLog
delete mode 100644 sim/moxie/ChangeLog
delete mode 100644 sim/msp430/ChangeLog
delete mode 100644 sim/or1k/ChangeLog
delete mode 100644 sim/ppc/ChangeLog
delete mode 100644 sim/ppc/ChangeLog.00
delete mode 100644 sim/pru/ChangeLog
delete mode 100644 sim/rl78/ChangeLog
delete mode 100644 sim/rx/ChangeLog
delete mode 100644 sim/sh/ChangeLog
delete mode 100644 sim/testsuite/ChangeLog
delete mode 100644 sim/testsuite/d10v-elf/ChangeLog
delete mode 100644 sim/testsuite/frv-elf/ChangeLog
delete mode 100644 sim/testsuite/m32r-elf/ChangeLog
delete mode 100644 sim/testsuite/mips64el-elf/ChangeLog
delete mode 100644 sim/testsuite/sim/aarch64/ChangeLog
delete mode 100644 sim/testsuite/sim/arm/ChangeLog
delete mode 100644 sim/testsuite/sim/avr/ChangeLog
delete mode 100644 sim/testsuite/sim/bfin/ChangeLog
delete mode 100644 sim/testsuite/sim/bpf/ChangeLog
delete mode 100644 sim/testsuite/sim/cr16/ChangeLog
delete mode 100644 sim/testsuite/sim/cris/ChangeLog
delete mode 100644 sim/testsuite/sim/frv/ChangeLog
delete mode 100644 sim/testsuite/sim/ft32/ChangeLog
delete mode 100644 sim/testsuite/sim/h8300/ChangeLog
delete mode 100644 sim/testsuite/sim/iq2000/ChangeLog
delete mode 100644 sim/testsuite/sim/lm32/ChangeLog
delete mode 100644 sim/testsuite/sim/m32c/ChangeLog
delete mode 100644 sim/testsuite/sim/m32r/ChangeLog
delete mode 100644 sim/testsuite/sim/m68hc11/ChangeLog
delete mode 100644 sim/testsuite/sim/mcore/ChangeLog
delete mode 100644 sim/testsuite/sim/microblaze/ChangeLog
delete mode 100644 sim/testsuite/sim/mips/ChangeLog
delete mode 100644 sim/testsuite/sim/mn10300/ChangeLog
delete mode 100644 sim/testsuite/sim/moxie/ChangeLog
delete mode 100644 sim/testsuite/sim/msp430/ChangeLog
delete mode 100644 sim/testsuite/sim/or1k/ChangeLog
delete mode 100644 sim/testsuite/sim/pru/ChangeLog
delete mode 100644 sim/testsuite/sim/sh/ChangeLog
delete mode 100644 sim/testsuite/sim/v850/ChangeLog
delete mode 100644 sim/v850/ChangeLog
diff --git a/src-release.sh b/src-release.sh
index d24a63c99b0a..d1898f6291ab 100755
--- a/src-release.sh
+++ b/src-release.sh
@@ -133,6 +133,12 @@ do_proto_toplev()
ln -s ../$d proto-toplev/$d
fi
fi
+
+ case $d in
+ sim)
+ ./gnulib/import/extra/gitlog-to-changelog -- $d/ >$d/ChangeLog
+ ;;
+ esac
done
(cd etc; $MAKE MAKEINFOFLAGS="$MAKEINFOFLAGS" info)
$MAKE distclean
--
2.28.0
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-10 3:42 ` [PATCH] sim: switch to autogenerated ChangeLog files Mike Frysinger
@ 2021-01-11 11:05 ` Andrew Burgess
2021-01-11 17:00 ` Simon Marchi
0 siblings, 1 reply; 21+ messages in thread
From: Andrew Burgess @ 2021-01-11 11:05 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
* Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org> [2021-01-09 22:42:23 -0500]:
> Use the gitlog-to-changelog gnulib script to automatically generate
> the ChangeLog file for the sim project in releases. This allows us
> to drop the manually curated ones.
Sorry, but no.
I think sim/ should follow the same policy as gdb/ for now. Do feel
free to raise this as a suggestion for gdb/ in general though, it
would be an interesting conversation to observe.
Thanks,
Andrew
>
> * src-release.sh (do_proto_toplev): Call gitlog-to-changelog when
> $d is sim.
> ---
> sim/ChangeLog | 1387 -----
> sim/aarch64/ChangeLog | 480 --
> sim/arm/ChangeLog | 1829 ------
> sim/avr/ChangeLog | 315 --
> sim/bfin/ChangeLog | 1205 ----
> sim/bpf/ChangeLog | 62 -
> sim/common/ChangeLog | 7245 ------------------------
> sim/cr16/ChangeLog | 504 --
> sim/cris/ChangeLog | 754 ---
> sim/d10v/ChangeLog | 1756 ------
> sim/erc32/ChangeLog | 1125 ----
> sim/frv/ChangeLog | 3025 ----------
> sim/ft32/ChangeLog | 189 -
> sim/h8300/ChangeLog | 1280 -----
> sim/igen/ChangeLog | 1272 -----
> sim/iq2000/ChangeLog | 577 --
> sim/lm32/ChangeLog | 387 --
> sim/m32c/ChangeLog | 428 --
> sim/m32r/ChangeLog | 2002 -------
> sim/m68hc11/ChangeLog | 1030 ----
> sim/mcore/ChangeLog | 578 --
> sim/microblaze/ChangeLog | 350 --
> sim/mips/ChangeLog | 3814 -------------
> sim/mn10300/ChangeLog | 1562 -----
> sim/moxie/ChangeLog | 543 --
> sim/msp430/ChangeLog | 339 --
> sim/or1k/ChangeLog | 60 -
> sim/ppc/ChangeLog | 4296 --------------
> sim/ppc/ChangeLog.00 | 2168 -------
> sim/pru/ChangeLog | 38 -
> sim/rl78/ChangeLog | 185 -
> sim/rx/ChangeLog | 395 --
> sim/sh/ChangeLog | 1662 ------
> sim/testsuite/ChangeLog | 371 --
> sim/testsuite/d10v-elf/ChangeLog | 139 -
> sim/testsuite/frv-elf/ChangeLog | 48 -
> sim/testsuite/m32r-elf/ChangeLog | 18 -
> sim/testsuite/mips64el-elf/ChangeLog | 19 -
> sim/testsuite/sim/aarch64/ChangeLog | 83 -
> sim/testsuite/sim/arm/ChangeLog | 122 -
> sim/testsuite/sim/avr/ChangeLog | 7 -
> sim/testsuite/sim/bfin/ChangeLog | 370 --
> sim/testsuite/sim/bpf/ChangeLog | 20 -
> sim/testsuite/sim/cr16/ChangeLog | 51 -
> sim/testsuite/sim/cris/ChangeLog | 197 -
> sim/testsuite/sim/frv/ChangeLog | 76 -
> sim/testsuite/sim/ft32/ChangeLog | 8 -
> sim/testsuite/sim/h8300/ChangeLog | 107 -
> sim/testsuite/sim/iq2000/ChangeLog | 3 -
> sim/testsuite/sim/lm32/ChangeLog | 3 -
> sim/testsuite/sim/m32c/ChangeLog | 10 -
> sim/testsuite/sim/m32r/ChangeLog | 122 -
> sim/testsuite/sim/m68hc11/ChangeLog | 3 -
> sim/testsuite/sim/mcore/ChangeLog | 8 -
> sim/testsuite/sim/microblaze/ChangeLog | 3 -
> sim/testsuite/sim/mips/ChangeLog | 118 -
> sim/testsuite/sim/mn10300/ChangeLog | 3 -
> sim/testsuite/sim/moxie/ChangeLog | 3 -
> sim/testsuite/sim/msp430/ChangeLog | 17 -
> sim/testsuite/sim/or1k/ChangeLog | 46 -
> sim/testsuite/sim/pru/ChangeLog | 17 -
> sim/testsuite/sim/sh/ChangeLog | 77 -
> sim/testsuite/sim/v850/ChangeLog | 19 -
> sim/v850/ChangeLog | 1695 ------
> src-release.sh | 6 +
> 65 files changed, 6 insertions(+), 46625 deletions(-)
> delete mode 100644 sim/ChangeLog
> delete mode 100644 sim/aarch64/ChangeLog
> delete mode 100644 sim/arm/ChangeLog
> delete mode 100644 sim/avr/ChangeLog
> delete mode 100644 sim/bfin/ChangeLog
> delete mode 100644 sim/bpf/ChangeLog
> delete mode 100644 sim/common/ChangeLog
> delete mode 100644 sim/cr16/ChangeLog
> delete mode 100644 sim/cris/ChangeLog
> delete mode 100644 sim/d10v/ChangeLog
> delete mode 100644 sim/erc32/ChangeLog
> delete mode 100644 sim/frv/ChangeLog
> delete mode 100644 sim/ft32/ChangeLog
> delete mode 100644 sim/h8300/ChangeLog
> delete mode 100644 sim/igen/ChangeLog
> delete mode 100644 sim/iq2000/ChangeLog
> delete mode 100644 sim/lm32/ChangeLog
> delete mode 100644 sim/m32c/ChangeLog
> delete mode 100644 sim/m32r/ChangeLog
> delete mode 100644 sim/m68hc11/ChangeLog
> delete mode 100644 sim/mcore/ChangeLog
> delete mode 100644 sim/microblaze/ChangeLog
> delete mode 100644 sim/mips/ChangeLog
> delete mode 100644 sim/mn10300/ChangeLog
> delete mode 100644 sim/moxie/ChangeLog
> delete mode 100644 sim/msp430/ChangeLog
> delete mode 100644 sim/or1k/ChangeLog
> delete mode 100644 sim/ppc/ChangeLog
> delete mode 100644 sim/ppc/ChangeLog.00
> delete mode 100644 sim/pru/ChangeLog
> delete mode 100644 sim/rl78/ChangeLog
> delete mode 100644 sim/rx/ChangeLog
> delete mode 100644 sim/sh/ChangeLog
> delete mode 100644 sim/testsuite/ChangeLog
> delete mode 100644 sim/testsuite/d10v-elf/ChangeLog
> delete mode 100644 sim/testsuite/frv-elf/ChangeLog
> delete mode 100644 sim/testsuite/m32r-elf/ChangeLog
> delete mode 100644 sim/testsuite/mips64el-elf/ChangeLog
> delete mode 100644 sim/testsuite/sim/aarch64/ChangeLog
> delete mode 100644 sim/testsuite/sim/arm/ChangeLog
> delete mode 100644 sim/testsuite/sim/avr/ChangeLog
> delete mode 100644 sim/testsuite/sim/bfin/ChangeLog
> delete mode 100644 sim/testsuite/sim/bpf/ChangeLog
> delete mode 100644 sim/testsuite/sim/cr16/ChangeLog
> delete mode 100644 sim/testsuite/sim/cris/ChangeLog
> delete mode 100644 sim/testsuite/sim/frv/ChangeLog
> delete mode 100644 sim/testsuite/sim/ft32/ChangeLog
> delete mode 100644 sim/testsuite/sim/h8300/ChangeLog
> delete mode 100644 sim/testsuite/sim/iq2000/ChangeLog
> delete mode 100644 sim/testsuite/sim/lm32/ChangeLog
> delete mode 100644 sim/testsuite/sim/m32c/ChangeLog
> delete mode 100644 sim/testsuite/sim/m32r/ChangeLog
> delete mode 100644 sim/testsuite/sim/m68hc11/ChangeLog
> delete mode 100644 sim/testsuite/sim/mcore/ChangeLog
> delete mode 100644 sim/testsuite/sim/microblaze/ChangeLog
> delete mode 100644 sim/testsuite/sim/mips/ChangeLog
> delete mode 100644 sim/testsuite/sim/mn10300/ChangeLog
> delete mode 100644 sim/testsuite/sim/moxie/ChangeLog
> delete mode 100644 sim/testsuite/sim/msp430/ChangeLog
> delete mode 100644 sim/testsuite/sim/or1k/ChangeLog
> delete mode 100644 sim/testsuite/sim/pru/ChangeLog
> delete mode 100644 sim/testsuite/sim/sh/ChangeLog
> delete mode 100644 sim/testsuite/sim/v850/ChangeLog
> delete mode 100644 sim/v850/ChangeLog
>
> diff --git a/src-release.sh b/src-release.sh
> index d24a63c99b0a..d1898f6291ab 100755
> --- a/src-release.sh
> +++ b/src-release.sh
> @@ -133,6 +133,12 @@ do_proto_toplev()
> ln -s ../$d proto-toplev/$d
> fi
> fi
> +
> + case $d in
> + sim)
> + ./gnulib/import/extra/gitlog-to-changelog -- $d/ >$d/ChangeLog
> + ;;
> + esac
> done
> (cd etc; $MAKE MAKEINFOFLAGS="$MAKEINFOFLAGS" info)
> $MAKE distclean
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 2/3] gnulib: import gitlog-to-changelog
2021-01-10 3:37 ` [PATCH 2/3] gnulib: import gitlog-to-changelog Mike Frysinger
@ 2021-01-11 11:06 ` Andrew Burgess
0 siblings, 0 replies; 21+ messages in thread
From: Andrew Burgess @ 2021-01-11 11:06 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
* Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org> [2021-01-09 22:37:51 -0500]:
> This is going to be used to generate ChangeLog files.
Please see my feedback on patch 3/3.
Thanks,
Andrew
>
> gnulib/:
>
> * update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add gitlog-to-changelog.
> * Makefile.in, configure: Regenerate.
> * import/Makefile.am, import/Makefile.in: Regenerate.
> * import/m4/gnulib-cache.m4: Regenerate.
> * import/m4/gnulib-comp.m4: Regenerate.
> * import/extra/gitlog-to-changelog: New file.
> ---
> gnulib/Makefile.in | 2 +-
> gnulib/configure | 1 +
> gnulib/import/Makefile.am | 8 +
> gnulib/import/Makefile.in | 14 +-
> gnulib/import/extra/gitlog-to-changelog | 515 ++++++++++++++++++++++++
> gnulib/import/m4/gnulib-cache.m4 | 2 +
> gnulib/import/m4/gnulib-comp.m4 | 2 +
> gnulib/update-gnulib.sh | 1 +
> 8 files changed, 538 insertions(+), 7 deletions(-)
> create mode 100755 gnulib/import/extra/gitlog-to-changelog
>
> diff --git a/gnulib/Makefile.in b/gnulib/Makefile.in
> index c1c216809446..69161b1f7ed5 100644
> --- a/gnulib/Makefile.in
> +++ b/gnulib/Makefile.in
> @@ -14,7 +14,7 @@
>
> @SET_MAKE@
>
> -# Copyright (C) 2019-2020 Free Software Foundation, Inc.
> +# Copyright (C) 2019-2021 Free Software Foundation, Inc.
>
> # This file is part of GDB.
>
> diff --git a/gnulib/configure b/gnulib/configure
> index 6c58a46e42ed..e4191103af58 100644
> --- a/gnulib/configure
> +++ b/gnulib/configure
> @@ -6608,6 +6608,7 @@ fi
> # Code from module getrandom:
> # Code from module gettext-h:
> # Code from module gettimeofday:
> + # Code from module gitlog-to-changelog:
> # Code from module glob:
> # Code from module glob-h:
> # Code from module hard-locale:
> diff --git a/gnulib/import/Makefile.am b/gnulib/import/Makefile.am
> index 84de424a1734..48a642febdcc 100644
> --- a/gnulib/import/Makefile.am
> +++ b/gnulib/import/Makefile.am
> @@ -43,6 +43,7 @@
> # frexpl \
> # getcwd \
> # gettimeofday \
> +# gitlog-to-changelog \
> # glob \
> # inet_ntop \
> # inttypes \
> @@ -703,6 +704,13 @@ EXTRA_libgnu_a_SOURCES += gettimeofday.c
>
> ## end gnulib module gettimeofday
>
> +## begin gnulib module gitlog-to-changelog
> +
> +
> +EXTRA_DIST += $(top_srcdir)/import/extra/gitlog-to-changelog
> +
> +## end gnulib module gitlog-to-changelog
> +
> ## begin gnulib module glob
>
>
> diff --git a/gnulib/import/Makefile.in b/gnulib/import/Makefile.in
> index 476cde8dd57e..7c61a29499af 100644
> --- a/gnulib/import/Makefile.in
> +++ b/gnulib/import/Makefile.in
> @@ -57,6 +57,7 @@
> # frexpl \
> # getcwd \
> # gettimeofday \
> +# gitlog-to-changelog \
> # glob \
> # inet_ntop \
> # inttypes \
> @@ -1689,12 +1690,13 @@ EXTRA_DIST = m4/gnulib-cache.m4 alloca.c alloca.in.h arpa_inet.in.h \
> fnmatch.c fnmatch_loop.c fnmatch.in.h fpucw.h frexp.c frexp.c \
> frexpl.c fstat.c stat-w32.c stat-w32.h at-func.c fstatat.c \
> getcwd.c getcwd-lgpl.c getdtablesize.c getlogin_r.c \
> - getrandom.c gettimeofday.c glob.c glob_internal.h \
> - glob_pattern_p.c globfree.c glob-libc.h glob.in.h \
> - hard-locale.h inet_ntop.c intprops.h inttypes.in.h isblank.c \
> - float+.h isnan.c isnand-nolibm.h isnand.c float+.h isnan.c \
> - isnanl-nolibm.h isnanl.c cdefs.h libc-config.h limits.in.h \
> - localcharset.h locale.in.h localtime-buffer.c \
> + getrandom.c gettimeofday.c \
> + $(top_srcdir)/import/extra/gitlog-to-changelog glob.c \
> + glob_internal.h glob_pattern_p.c globfree.c glob-libc.h \
> + glob.in.h hard-locale.h inet_ntop.c intprops.h inttypes.in.h \
> + isblank.c float+.h isnan.c isnand-nolibm.h isnand.c float+.h \
> + isnan.c isnanl-nolibm.h isnanl.c cdefs.h libc-config.h \
> + limits.in.h localcharset.h locale.in.h localtime-buffer.c \
> localtime-buffer.h lstat.c malloc.c malloca.h math.in.h \
> lc-charset-dispatch.c lc-charset-dispatch.h \
> mbrtowc-impl-utf8.h mbrtowc-impl.h mbrtowc.c mbtowc-lock.c \
> diff --git a/gnulib/import/extra/gitlog-to-changelog b/gnulib/import/extra/gitlog-to-changelog
> new file mode 100755
> index 000000000000..be8082e7ffd9
> --- /dev/null
> +++ b/gnulib/import/extra/gitlog-to-changelog
> @@ -0,0 +1,515 @@
> +#!/bin/sh
> +#! -*-perl-*-
> +
> +# Convert git log output to ChangeLog format.
> +
> +# Copyright (C) 2008-2020 Free Software Foundation, Inc.
> +#
> +# This program is free software: you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation, either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see <https://www.gnu.org/licenses/>.
> +#
> +# Written by Jim Meyering
> +
> +# This is a prologue that allows to run a perl script as an executable
> +# on systems that are compliant to a POSIX version before POSIX:2017.
> +# On such systems, the usual invocation of an executable through execlp()
> +# or execvp() fails with ENOEXEC if it is a script that does not start
> +# with a #! line. The script interpreter mentioned in the #! line has
> +# to be /bin/sh, because on GuixSD systems that is the only program that
> +# has a fixed file name. The second line is essential for perl and is
> +# also useful for editing this file in Emacs. The next two lines below
> +# are valid code in both sh and perl. When executed by sh, they re-execute
> +# the script through the perl program found in $PATH. The '-x' option
> +# is essential as well; without it, perl would re-execute the script
> +# through /bin/sh. When executed by perl, the next two lines are a no-op.
> +eval 'exec perl -wSx "$0" "$@"'
> + if 0;
> +
> +my $VERSION = '2020-04-04 15:07'; # UTC
> +# The definition above must lie within the first 8 lines in order
> +# for the Emacs time-stamp write hook (at end) to update it.
> +# If you change this file with Emacs, please let the write hook
> +# do its job. Otherwise, update this string manually.
> +
> +use strict;
> +use warnings;
> +use Getopt::Long;
> +use POSIX qw(strftime);
> +
> +(my $ME = $0) =~ s|.*/||;
> +
> +# use File::Coda; # https://meyering.net/code/Coda/
> +END {
> + defined fileno STDOUT or return;
> + close STDOUT and return;
> + warn "$ME: failed to close standard output: $!\n";
> + $? ||= 1;
> +}
> +
> +sub usage ($)
> +{
> + my ($exit_code) = @_;
> + my $STREAM = ($exit_code == 0 ? *STDOUT : *STDERR);
> + if ($exit_code != 0)
> + {
> + print $STREAM "Try '$ME --help' for more information.\n";
> + }
> + else
> + {
> + print $STREAM <<EOF;
> +Usage: $ME [OPTIONS] [ARGS]
> +
> +Convert git log output to ChangeLog format. If present, any ARGS
> +are passed to "git log". To avoid ARGS being parsed as options to
> +$ME, they may be preceded by '--'.
> +
> +OPTIONS:
> +
> + --amend=FILE FILE maps from an SHA1 to perl code (i.e., s/old/new/) that
> + makes a change to SHA1's commit log text or metadata.
> + --append-dot append a dot to the first line of each commit message if
> + there is no other punctuation or blank at the end.
> + --no-cluster never cluster commit messages under the same date/author
> + header; the default is to cluster adjacent commit messages
> + if their headers are the same and neither commit message
> + contains multiple paragraphs.
> + --srcdir=DIR the root of the source tree, from which the .git/
> + directory can be derived.
> + --since=DATE convert only the logs since DATE;
> + the default is to convert all log entries.
> + --until=DATE convert only the logs older than DATE.
> + --ignore-matching=PAT ignore commit messages whose first lines match PAT.
> + --ignore-line=PAT ignore lines of commit messages that match PAT.
> + --format=FMT set format string for commit subject and body;
> + see 'man git-log' for the list of format metacharacters;
> + the default is '%s%n%b%n'
> + --strip-tab remove one additional leading TAB from commit message lines.
> + --strip-cherry-pick remove data inserted by "git cherry-pick";
> + this includes the "cherry picked from commit ..." line,
> + and the possible final "Conflicts:" paragraph.
> + --help display this help and exit
> + --version output version information and exit
> +
> +EXAMPLE:
> +
> + $ME --since=2008-01-01 > ChangeLog
> + $ME -- -n 5 foo > last-5-commits-to-branch-foo
> +
> +SPECIAL SYNTAX:
> +
> +The following types of strings are interpreted specially when they appear
> +at the beginning of a log message line. They are not copied to the output.
> +
> + Copyright-paperwork-exempt: Yes
> + Append the "(tiny change)" notation to the usual "date name email"
> + ChangeLog header to mark a change that does not require a copyright
> + assignment.
> + Co-authored-by: Joe User <user\@example.com>
> + List the specified name and email address on a second
> + ChangeLog header, denoting a co-author.
> + Signed-off-by: Joe User <user\@example.com>
> + These lines are simply elided.
> +
> +In a FILE specified via --amend, comment lines (starting with "#") are ignored.
> +FILE must consist of <SHA,CODE+> pairs where SHA is a 40-byte SHA1 (alone on
> +a line) referring to a commit in the current project, and CODE refers to one
> +or more consecutive lines of Perl code. Pairs must be separated by one or
> +more blank line.
> +
> +Here is sample input for use with --amend=FILE, from coreutils:
> +
> +3a169f4c5d9159283548178668d2fae6fced3030
> +# fix typo in title:
> +s/all tile types/all file types/
> +
> +1379ed974f1fa39b12e2ffab18b3f7a607082202
> +# Due to a bug in vc-dwim, I mis-attributed a patch by Paul to myself.
> +# Change the author to be Paul. Note the escaped "@":
> +s,Jim .*>,Paul Eggert <eggert\\\@cs.ucla.edu>,
> +
> +EOF
> + }
> + exit $exit_code;
> +}
> +
> +# If the string $S is a well-behaved file name, simply return it.
> +# If it contains white space, quotes, etc., quote it, and return the new string.
> +sub shell_quote($)
> +{
> + my ($s) = @_;
> + if ($s =~ m![^\w+/.,-]!)
> + {
> + # Convert each single quote to '\''
> + $s =~ s/\'/\'\\\'\'/g;
> + # Then single quote the string.
> + $s = "'$s'";
> + }
> + return $s;
> +}
> +
> +sub quoted_cmd(@)
> +{
> + return join (' ', map {shell_quote $_} @_);
> +}
> +
> +# Parse file F.
> +# Comment lines (starting with "#") are ignored.
> +# F must consist of <SHA,CODE+> pairs where SHA is a 40-byte SHA1
> +# (alone on a line) referring to a commit in the current project, and
> +# CODE refers to one or more consecutive lines of Perl code.
> +# Pairs must be separated by one or more blank line.
> +sub parse_amend_file($)
> +{
> + my ($f) = @_;
> +
> + open F, '<', $f
> + or die "$ME: $f: failed to open for reading: $!\n";
> +
> + my $fail;
> + my $h = {};
> + my $in_code = 0;
> + my $sha;
> + while (defined (my $line = <F>))
> + {
> + $line =~ /^\#/
> + and next;
> + chomp $line;
> + $line eq ''
> + and $in_code = 0, next;
> +
> + if (!$in_code)
> + {
> + $line =~ /^([[:xdigit:]]{40})$/
> + or (warn "$ME: $f:$.: invalid line; expected an SHA1\n"),
> + $fail = 1, next;
> + $sha = lc $1;
> + $in_code = 1;
> + exists $h->{$sha}
> + and (warn "$ME: $f:$.: duplicate SHA1\n"),
> + $fail = 1, next;
> + }
> + else
> + {
> + $h->{$sha} ||= '';
> + $h->{$sha} .= "$line\n";
> + }
> + }
> + close F;
> +
> + $fail
> + and exit 1;
> +
> + return $h;
> +}
> +
> +# git_dir_option $SRCDIR
> +#
> +# From $SRCDIR, the --git-dir option to pass to git (none if $SRCDIR
> +# is undef). Return as a list (0 or 1 element).
> +sub git_dir_option($)
> +{
> + my ($srcdir) = @_;
> + my @res = ();
> + if (defined $srcdir)
> + {
> + my $qdir = shell_quote $srcdir;
> + my $cmd = "cd $qdir && git rev-parse --show-toplevel";
> + my $qcmd = shell_quote $cmd;
> + my $git_dir = qx($cmd);
> + defined $git_dir
> + or die "$ME: cannot run $qcmd: $!\n";
> + $? == 0
> + or die "$ME: $qcmd had unexpected exit code or signal ($?)\n";
> + chomp $git_dir;
> + push @res, "--git-dir=$git_dir/.git";
> + }
> + @res;
> +}
> +
> +{
> + my $since_date;
> + my $until_date;
> + my $format_string = '%s%n%b%n';
> + my $amend_file;
> + my $append_dot = 0;
> + my $cluster = 1;
> + my $ignore_matching;
> + my $ignore_line;
> + my $strip_tab = 0;
> + my $strip_cherry_pick = 0;
> + my $srcdir;
> + GetOptions
> + (
> + help => sub { usage 0 },
> + version => sub { print "$ME version $VERSION\n"; exit },
> + 'since=s' => \$since_date,
> + 'until=s' => \$until_date,
> + 'format=s' => \$format_string,
> + 'amend=s' => \$amend_file,
> + 'append-dot' => \$append_dot,
> + 'cluster!' => \$cluster,
> + 'ignore-matching=s' => \$ignore_matching,
> + 'ignore-line=s' => \$ignore_line,
> + 'strip-tab' => \$strip_tab,
> + 'strip-cherry-pick' => \$strip_cherry_pick,
> + 'srcdir=s' => \$srcdir,
> + ) or usage 1;
> +
> + defined $since_date
> + and unshift @ARGV, "--since=$since_date";
> + defined $until_date
> + and unshift @ARGV, "--until=$until_date";
> +
> + # This is a hash that maps an SHA1 to perl code (i.e., s/old/new/)
> + # that makes a correction in the log or attribution of that commit.
> + my $amend_code = defined $amend_file ? parse_amend_file $amend_file : {};
> +
> + my @cmd = ('git',
> + git_dir_option $srcdir,
> + qw(log --log-size),
> + '--pretty=format:%H:%ct %an <%ae>%n%n'.$format_string, @ARGV);
> + open PIPE, '-|', @cmd
> + or die ("$ME: failed to run '". quoted_cmd (@cmd) ."': $!\n"
> + . "(Is your Git too old? Version 1.5.1 or later is required.)\n");
> +
> + my $prev_multi_paragraph;
> + my $prev_date_line = '';
> + my @prev_coauthors = ();
> + my @skipshas = ();
> + while (1)
> + {
> + defined (my $in = <PIPE>)
> + or last;
> + $in =~ /^log size (\d+)$/
> + or die "$ME:$.: Invalid line (expected log size):\n$in";
> + my $log_nbytes = $1;
> +
> + my $log;
> + my $n_read = read PIPE, $log, $log_nbytes;
> + $n_read == $log_nbytes
> + or die "$ME:$.: unexpected EOF\n";
> +
> + # Extract leading hash.
> + my ($sha, $rest) = split ':', $log, 2;
> + defined $sha
> + or die "$ME:$.: malformed log entry\n";
> + $sha =~ /^[[:xdigit:]]{40}$/
> + or die "$ME:$.: invalid SHA1: $sha\n";
> +
> + my $skipflag = 0;
> + if (@skipshas)
> + {
> + foreach(@skipshas)
> + {
> + if ($sha =~ /^$_/)
> + {
> + $skipflag = $_;
> + last;
> + }
> + }
> + }
> +
> + # If this commit's log requires any transformation, do it now.
> + my $code = $amend_code->{$sha};
> + if (defined $code)
> + {
> + eval 'use Safe';
> + my $s = new Safe;
> + # Put the unpreprocessed entry into "$_".
> + $_ = $rest;
> +
> + # Let $code operate on it, safely.
> + my $r = $s->reval("$code")
> + or die "$ME:$.:$sha: failed to eval \"$code\":\n$@\n";
> +
> + # Note that we've used this entry.
> + delete $amend_code->{$sha};
> +
> + # Update $rest upon success.
> + $rest = $_;
> + }
> +
> + # Remove lines inserted by "git cherry-pick".
> + if ($strip_cherry_pick)
> + {
> + $rest =~ s/^\s*Conflicts:\n.*//sm;
> + $rest =~ s/^\s*\(cherry picked from commit [\da-f]+\)\n//m;
> + }
> +
> + my @line = split /[ \t]*\n/, $rest;
> + my $author_line = shift @line;
> + defined $author_line
> + or die "$ME:$.: unexpected EOF\n";
> + $author_line =~ /^(\d+) (.*>)$/
> + or die "$ME:$.: Invalid line "
> + . "(expected date/author/email):\n$author_line\n";
> +
> + # Format 'Copyright-paperwork-exempt: Yes' as a standard ChangeLog
> + # `(tiny change)' annotation.
> + my $tiny = (grep (/^(?:Copyright-paperwork-exempt|Tiny-change):\s+[Yy]es$/, @line)
> + ? ' (tiny change)' : '');
> +
> + my $date_line = sprintf "%s %s$tiny\n",
> + strftime ("%Y-%m-%d", localtime ($1)), $2;
> +
> + my @coauthors = grep /^Co-authored-by:.*$/, @line;
> + # Omit meta-data lines we've already interpreted.
> + @line = grep !/^(?:Signed-off-by:[ ].*>$
> + |Co-authored-by:[ ]
> + |Copyright-paperwork-exempt:[ ]
> + |Tiny-change:[ ]
> + )/x, @line;
> +
> + # Remove leading and trailing blank lines.
> + if (@line)
> + {
> + while ($line[0] =~ /^\s*$/) { shift @line; }
> + while ($line[$#line] =~ /^\s*$/) { pop @line; }
> + }
> +
> + # Handle Emacs gitmerge.el "skipped" commits.
> + # Yes, this should be controlled by an option. So sue me.
> + if ( grep /^(; )?Merge from /, @line )
> + {
> + my $found = 0;
> + foreach (@line)
> + {
> + if (grep /^The following commit.*skipped:$/, $_)
> + {
> + $found = 1;
> + ## Reset at each merge to reduce chance of false matches.
> + @skipshas = ();
> + next;
> + }
> + if ($found && $_ =~ /^([[:xdigit:]]{7,}) [^ ]/)
> + {
> + push ( @skipshas, $1 );
> + }
> + }
> + }
> +
> + # Ignore commits that match the --ignore-matching pattern, if specified.
> + if (defined $ignore_matching && @line && $line[0] =~ /$ignore_matching/)
> + {
> + $skipflag = 1;
> + }
> + elsif ($skipflag)
> + {
> + ## Perhaps only warn if a pattern matches more than once?
> + warn "$ME: warning: skipping $sha due to $skipflag\n";
> + }
> +
> + if (! $skipflag)
> + {
> + if (defined $ignore_line && @line)
> + {
> + @line = grep ! /$ignore_line/, @line;
> + while ($line[$#line] =~ /^\s*$/) { pop @line; }
> + }
> +
> + # Record whether there are two or more paragraphs.
> + my $multi_paragraph = grep /^\s*$/, @line;
> +
> + # Format 'Co-authored-by: A U Thor <email@example.com>' lines in
> + # standard multi-author ChangeLog format.
> + for (@coauthors)
> + {
> + s/^Co-authored-by:\s*/\t /;
> + s/\s*</ </;
> +
> + /<.*?@.*\..*>/
> + or warn "$ME: warning: missing email address for "
> + . substr ($_, 5) . "\n";
> + }
> +
> + # If clustering of commit messages has been disabled, if this header
> + # would be different from the previous date/name/etc. header,
> + # or if this or the previous entry consists of two or more paragraphs,
> + # then print the header.
> + if ( ! $cluster
> + || $date_line ne $prev_date_line
> + || "@coauthors" ne "@prev_coauthors"
> + || $multi_paragraph
> + || $prev_multi_paragraph)
> + {
> + $prev_date_line eq ''
> + or print "\n";
> + print $date_line;
> + @coauthors
> + and print join ("\n", @coauthors), "\n";
> + }
> + $prev_date_line = $date_line;
> + @prev_coauthors = @coauthors;
> + $prev_multi_paragraph = $multi_paragraph;
> +
> + # If there were any lines
> + if (@line == 0)
> + {
> + warn "$ME: warning: empty commit message:\n $date_line\n";
> + }
> + else
> + {
> + if ($append_dot)
> + {
> + # If the first line of the message has enough room, then
> + if (length $line[0] < 72)
> + {
> + # append a dot if there is no other punctuation or blank
> + # at the end.
> + $line[0] =~ /[[:punct:]\s]$/
> + or $line[0] .= '.';
> + }
> + }
> +
> + # Remove one additional leading TAB from each line.
> + $strip_tab
> + and map { s/^\t// } @line;
> +
> + # Prefix each non-empty line with a TAB.
> + @line = map { length $_ ? "\t$_" : '' } @line;
> +
> + print "\n", join ("\n", @line), "\n";
> + }
> + }
> +
> + defined ($in = <PIPE>)
> + or last;
> + $in ne "\n"
> + and die "$ME:$.: unexpected line:\n$in";
> + }
> +
> + close PIPE
> + or die "$ME: error closing pipe from " . quoted_cmd (@cmd) . "\n";
> + # FIXME-someday: include $PROCESS_STATUS in the diagnostic
> +
> + # Complain about any unused entry in the --amend=F specified file.
> + my $fail = 0;
> + foreach my $sha (keys %$amend_code)
> + {
> + warn "$ME:$amend_file: unused entry: $sha\n";
> + $fail = 1;
> + }
> +
> + exit $fail;
> +}
> +
> +# Local Variables:
> +# mode: perl
> +# indent-tabs-mode: nil
> +# eval: (add-hook 'before-save-hook 'time-stamp)
> +# time-stamp-line-limit: 50
> +# time-stamp-start: "my $VERSION = '"
> +# time-stamp-format: "%:y-%02m-%02d %02H:%02M"
> +# time-stamp-time-zone: "UTC0"
> +# time-stamp-end: "'; # UTC"
> +# End:
> diff --git a/gnulib/import/m4/gnulib-cache.m4 b/gnulib/import/m4/gnulib-cache.m4
> index db95504cc6ad..c0b6d4119466 100644
> --- a/gnulib/import/m4/gnulib-cache.m4
> +++ b/gnulib/import/m4/gnulib-cache.m4
> @@ -48,6 +48,7 @@
> # frexpl \
> # getcwd \
> # gettimeofday \
> +# gitlog-to-changelog \
> # glob \
> # inet_ntop \
> # inttypes \
> @@ -89,6 +90,7 @@ gl_MODULES([
> frexpl
> getcwd
> gettimeofday
> + gitlog-to-changelog
> glob
> inet_ntop
> inttypes
> diff --git a/gnulib/import/m4/gnulib-comp.m4 b/gnulib/import/m4/gnulib-comp.m4
> index 8c2c28ec932f..61d60db35954 100644
> --- a/gnulib/import/m4/gnulib-comp.m4
> +++ b/gnulib/import/m4/gnulib-comp.m4
> @@ -103,6 +103,7 @@ AC_DEFUN([gl_EARLY],
> # Code from module getrandom:
> # Code from module gettext-h:
> # Code from module gettimeofday:
> + # Code from module gitlog-to-changelog:
> # Code from module glob:
> # Code from module glob-h:
> # Code from module hard-locale:
> @@ -907,6 +908,7 @@ AC_DEFUN([gltests_LIBSOURCES], [
> # This macro records the list of files which have been installed by
> # gnulib-tool and may be removed by future gnulib-tool invocations.
> AC_DEFUN([gl_FILE_LIST], [
> + build-aux/gitlog-to-changelog
> build-aux/update-copyright
> lib/_Noreturn.h
> lib/alloca.c
> diff --git a/gnulib/update-gnulib.sh b/gnulib/update-gnulib.sh
> index e9b377ca4759..4820277e5fa9 100755
> --- a/gnulib/update-gnulib.sh
> +++ b/gnulib/update-gnulib.sh
> @@ -40,6 +40,7 @@ IMPORTED_GNULIB_MODULES="\
> frexpl \
> getcwd \
> gettimeofday \
> + gitlog-to-changelog \
> glob \
> inet_ntop
> inttypes \
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-11 11:05 ` Andrew Burgess
@ 2021-01-11 17:00 ` Simon Marchi
2021-01-11 17:10 ` Luis Machado
2021-01-11 19:38 ` Mike Frysinger
0 siblings, 2 replies; 21+ messages in thread
From: Simon Marchi @ 2021-01-11 17:00 UTC (permalink / raw)
To: Andrew Burgess, Mike Frysinger; +Cc: gdb-patches
On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
> I think sim/ should follow the same policy as gdb/ for now. Do feel
> free to raise this as a suggestion for gdb/ in general though, it
> would be an interesting conversation to observe.
Last time I tried the gitlog-to-changelog script on GDB, it produced
horrible results. Probably because it was not designed for C++.
Making a script to produce ChangeLogs for C code is already very
difficult, making it work with good results for C++ would be even
worst. And most importantly, I think it would be wasted development
time.
My opinion is that we should either keep hand-written ChangeLogs, or
admit that ChangeLogs are not useful and get rid of them altogether
(and you know which side I lean towards). But auto-generating
ChangeLogs, other than allowing to check the "we have ChangeLog" box,
doesn't produce anything useful.
Simon
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-11 17:00 ` Simon Marchi
@ 2021-01-11 17:10 ` Luis Machado
2021-01-11 17:31 ` Christian Biesinger
2021-01-11 19:38 ` Mike Frysinger
1 sibling, 1 reply; 21+ messages in thread
From: Luis Machado @ 2021-01-11 17:10 UTC (permalink / raw)
To: Simon Marchi, Andrew Burgess, Mike Frysinger; +Cc: gdb-patches
On 1/11/21 2:00 PM, Simon Marchi via Gdb-patches wrote:
> On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
>> I think sim/ should follow the same policy as gdb/ for now. Do feel
>> free to raise this as a suggestion for gdb/ in general though, it
>> would be an interesting conversation to observe.
>
> Last time I tried the gitlog-to-changelog script on GDB, it produced
> horrible results. Probably because it was not designed for C++.
>
> Making a script to produce ChangeLogs for C code is already very
> difficult, making it work with good results for C++ would be even
> worst. And most importantly, I think it would be wasted development
> time.
>
> My opinion is that we should either keep hand-written ChangeLogs, or
> admit that ChangeLogs are not useful and get rid of them altogether
> (and you know which side I lean towards). But auto-generating
> ChangeLogs, other than allowing to check the "we have ChangeLog" box,
> doesn't produce anything useful.
Ever since we moved binutils-gdb to git, ChangeLog's started to feel
like a waste of time. Now, with broader use of C++, it is even worse. It
makes things more verbose and harder for tools to find the right scope
(is the change in a function? A class? A member function?). And the
limit of 80 columns adds to that burden, since we need to watch out for
the length of the line. It feels like a puzzle sometimes.
"git log" produces very useful information, and we make the commit
messages very verbose (more than other projects) so developers can have
a pretty good idea of what has changed and why.
I'm strongly in favor of dropping ChangeLog's from GDB.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-11 17:10 ` Luis Machado
@ 2021-01-11 17:31 ` Christian Biesinger
0 siblings, 0 replies; 21+ messages in thread
From: Christian Biesinger @ 2021-01-11 17:31 UTC (permalink / raw)
To: Luis Machado; +Cc: Simon Marchi, Andrew Burgess, Mike Frysinger, gdb-patches
On Mon, Jan 11, 2021 at 6:10 PM Luis Machado via Gdb-patches
<gdb-patches@sourceware.org> wrote:
>
> On 1/11/21 2:00 PM, Simon Marchi via Gdb-patches wrote:
> > On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
> >> I think sim/ should follow the same policy as gdb/ for now. Do feel
> >> free to raise this as a suggestion for gdb/ in general though, it
> >> would be an interesting conversation to observe.
> >
> > Last time I tried the gitlog-to-changelog script on GDB, it produced
> > horrible results. Probably because it was not designed for C++.
> >
> > Making a script to produce ChangeLogs for C code is already very
> > difficult, making it work with good results for C++ would be even
> > worst. And most importantly, I think it would be wasted development
> > time.
> >
> > My opinion is that we should either keep hand-written ChangeLogs, or
> > admit that ChangeLogs are not useful and get rid of them altogether
> > (and you know which side I lean towards). But auto-generating
> > ChangeLogs, other than allowing to check the "we have ChangeLog" box,
> > doesn't produce anything useful.
>
> Ever since we moved binutils-gdb to git, ChangeLog's started to feel
> like a waste of time. Now, with broader use of C++, it is even worse. It
> makes things more verbose and harder for tools to find the right scope
> (is the change in a function? A class? A member function?). And the
> limit of 80 columns adds to that burden, since we need to watch out for
> the length of the line. It feels like a puzzle sometimes.
>
> "git log" produces very useful information, and we make the commit
> messages very verbose (more than other projects) so developers can have
> a pretty good idea of what has changed and why.
>
> I'm strongly in favor of dropping ChangeLog's from GDB.
I would love this as well.
There was some discussion almost a year ago in a thread titled "Using
the vcs_to_changelog.py script"
(https://sourceware.org/pipermail/gdb-patches/2020-February/165728.html)
Christian
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-11 17:00 ` Simon Marchi
2021-01-11 17:10 ` Luis Machado
@ 2021-01-11 19:38 ` Mike Frysinger
2021-01-11 19:54 ` Simon Marchi
2021-01-12 10:47 ` Andrew Burgess
1 sibling, 2 replies; 21+ messages in thread
From: Mike Frysinger @ 2021-01-11 19:38 UTC (permalink / raw)
To: Simon Marchi; +Cc: Andrew Burgess, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
On 11 Jan 2021 12:00, Simon Marchi wrote:
> On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
> > I think sim/ should follow the same policy as gdb/ for now. Do feel
> > free to raise this as a suggestion for gdb/ in general though, it
> > would be an interesting conversation to observe.
>
> Last time I tried the gitlog-to-changelog script on GDB, it produced
> horrible results. Probably because it was not designed for C++.
>
> Making a script to produce ChangeLogs for C code is already very
> difficult, making it work with good results for C++ would be even
> worst. And most importantly, I think it would be wasted development
> time.
to be clear, it isn't generating entries exactly like we write. it's
using the git commit logs with formatted dates. so i don't think this
applies exactly anymore. so it's inline with the GNU's VCS principles:
https://www.gnu.org/prep/standards/html_node/Change-Logs.html
(and that also recommends just using gitlog-to-changelog).
> My opinion is that we should either keep hand-written ChangeLogs, or
> admit that ChangeLogs are not useful and get rid of them altogether
> (and you know which side I lean towards). But auto-generating
> ChangeLogs, other than allowing to check the "we have ChangeLog" box,
> doesn't produce anything useful.
i'm obviously a huge +1 for this ;)
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-11 19:38 ` Mike Frysinger
@ 2021-01-11 19:54 ` Simon Marchi
2021-01-11 20:35 ` Mike Frysinger
2021-01-12 10:47 ` Andrew Burgess
1 sibling, 1 reply; 21+ messages in thread
From: Simon Marchi @ 2021-01-11 19:54 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
On 2021-01-11 2:38 p.m., Mike Frysinger wrote:
> to be clear, it isn't generating entries exactly like we write. it's
> using the git commit logs with formatted dates. so i don't think this
> applies exactly anymore. so it's inline with the GNU's VCS principles:
> https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> (and that also recommends just using gitlog-to-changelog).
Oh ok, I confused that script with vcs-to-changelog then!
https://www.gnu.org/software/gnulib/manual/html_node/VCS-To-ChangeLog.html
Just for reference, here's an excerpt of what vcs-to-changelog generates
for the patch I am currently working on:
* gdb/infrun.c: Modified.
(do_target_resume): Modified function.
(restore_thread): Modified.
(for): Modified function.
(check_multi_target_resumption): Modified function.
(gdb_assert): Modified.
(save_defer_tc): Remove.
(maybe_commit_resume_all_process_targets): Remove.
(release): Modified.
(return): Modified.
(gdb_assert): Modified.
(if): Modified function.
(return): Modified.
(return): Modified.
(return): Modified.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(gdb_assert): Modified.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(gdb_assert): Modified.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(if): Modified function.
(if): Modified function.
... and that goes on ...
Hopefully that explains why I said "horrible results" :).
Simon
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-11 19:54 ` Simon Marchi
@ 2021-01-11 20:35 ` Mike Frysinger
0 siblings, 0 replies; 21+ messages in thread
From: Mike Frysinger @ 2021-01-11 20:35 UTC (permalink / raw)
To: Simon Marchi; +Cc: Andrew Burgess, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
On 11 Jan 2021 14:54, Simon Marchi via Gdb-patches wrote:
> On 2021-01-11 2:38 p.m., Mike Frysinger wrote:
> > to be clear, it isn't generating entries exactly like we write. it's
> > using the git commit logs with formatted dates. so i don't think this
> > applies exactly anymore. so it's inline with the GNU's VCS principles:
> > https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> > (and that also recommends just using gitlog-to-changelog).
>
> Oh ok, I confused that script with vcs-to-changelog then!
>
> https://www.gnu.org/software/gnulib/manual/html_node/VCS-To-ChangeLog.html
>
> Just for reference, here's an excerpt of what vcs-to-changelog generates
> for the patch I am currently working on:
oh yeah, i tried that script too, and it was ... not ideal :).
it at least copies & pastes filenames so you don't have to extract
them, but i wouldn't expect much more out of it.
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-11 19:38 ` Mike Frysinger
2021-01-11 19:54 ` Simon Marchi
@ 2021-01-12 10:47 ` Andrew Burgess
2021-01-12 18:14 ` Joseph Myers
` (2 more replies)
1 sibling, 3 replies; 21+ messages in thread
From: Andrew Burgess @ 2021-01-12 10:47 UTC (permalink / raw)
To: gdb-patches
* Mike Frysinger <vapier@gentoo.org> [2021-01-11 14:38:30 -0500]:
> On 11 Jan 2021 12:00, Simon Marchi wrote:
> > On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
> > > I think sim/ should follow the same policy as gdb/ for now. Do feel
> > > free to raise this as a suggestion for gdb/ in general though, it
> > > would be an interesting conversation to observe.
> >
> > Last time I tried the gitlog-to-changelog script on GDB, it produced
> > horrible results. Probably because it was not designed for C++.
> >
> > Making a script to produce ChangeLogs for C code is already very
> > difficult, making it work with good results for C++ would be even
> > worst. And most importantly, I think it would be wasted development
> > time.
>
> to be clear, it isn't generating entries exactly like we write. it's
> using the git commit logs with formatted dates. so i don't think this
> applies exactly anymore. so it's inline with the GNU's VCS principles:
> https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> (and that also recommends just using gitlog-to-changelog).
I read this page, and especially the part that talks about using
gitlog-to-changelog, and I don't find their argument compelling.
Early in the page they list some uses for ChangeLogs, which basically
boils down to performing "software forensics". Their benefits are all
good, but IMHO are all covered (and covered better) by what the VCS
provide.
At the end of the page they say if you don't maintain a ChangeLog then
use a script to generate one in case people want to look at the
ChangeLog. But they fail to explain what use a ChangeLog is in a
release tree. The same argument could just as easily be used to
justify including a poem in the release; it should be there in case
someone wants to look at it.
For me the question is what benefit does a ChangeLog offer in a
release tree? When I look through the 7 points (in favour of
ChangeLogs) raised on the above page I don't see what value any of
those things have given only a release tree.
If we really wanted to include something informative inside each
release then I'd be most tempted to just do something like:
git log --stat last-release-tag...new-release-tag > GIT-LOG
That would give people a far more detailed understanding of what has
changed.
But honestly, I don't think it's unreasonable to say that if someone
wants to dig into the source history, just clone the repo.... and let
ChangeLogs burn!
Thanks,
Andrew
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-12 10:47 ` Andrew Burgess
@ 2021-01-12 18:14 ` Joseph Myers
2021-01-12 18:27 ` Eli Zaretskii
2021-01-12 21:27 ` Mike Frysinger
2021-01-12 21:22 ` Mike Frysinger
2021-03-09 5:51 ` Mike Frysinger
2 siblings, 2 replies; 21+ messages in thread
From: Joseph Myers @ 2021-01-12 18:14 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
On Tue, 12 Jan 2021, Andrew Burgess wrote:
> > to be clear, it isn't generating entries exactly like we write. it's
> > using the git commit logs with formatted dates. so i don't think this
> > applies exactly anymore. so it's inline with the GNU's VCS principles:
> > https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> > (and that also recommends just using gitlog-to-changelog).
>
> I read this page, and especially the part that talks about using
> gitlog-to-changelog, and I don't find their argument compelling.
What the GNU Coding Standards say about ChangeLogs isn't what would make
sense from a starting point of modern development practices, it's what we
could convince the maintainers of the GNU Coding Standards (being used to
ChangeLog-centric development practices) to allow.
The discussion started at
<https://lists.gnu.org/archive/html/bug-standards/2017-07/msg00000.html>
and took a few years (a few bits were on an internal GNU Project list, but
most was on bug-standards). In particular, the maintainers of the GNU
Coding Standards fixated on a point that they were used to using the lists
of changes to named entities (functions etc.) in ChangeLogs as part of the
debugging process, while my position is that the typical problem for which
such lists are used is not "map a commit to the named entities modified in
that change" but the inverse problem "map a named entity to the commits
changing it", which version control tools handle well without needing to
go via the ChangeLog-format lists at all.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-12 18:14 ` Joseph Myers
@ 2021-01-12 18:27 ` Eli Zaretskii
2021-01-12 18:40 ` Eli Zaretskii
2021-01-12 21:27 ` Mike Frysinger
1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2021-01-12 18:27 UTC (permalink / raw)
To: Joseph Myers; +Cc: andrew.burgess, gdb-patches
> Date: Tue, 12 Jan 2021 18:14:22 +0000
> From: Joseph Myers <joseph@codesourcery.com>
> Cc: gdb-patches@sourceware.org
>
> What the GNU Coding Standards say about ChangeLogs isn't what would make
> sense from a starting point of modern development practices, it's what we
> could convince the maintainers of the GNU Coding Standards (being used to
> ChangeLog-centric development practices) to allow.
When did you last read the current text of GSoC, specifically the part
related to change logs?
The fact is that you did convince, and the text was modified to allow
the MO which you argued for, as one possible alternative.
> The discussion started at
> <https://lists.gnu.org/archive/html/bug-standards/2017-07/msg00000.html>
> and took a few years (a few bits were on an internal GNU Project list, but
> most was on bug-standards). In particular, the maintainers of the GNU
> Coding Standards fixated on a point that they were used to using the lists
> of changes to named entities (functions etc.) in ChangeLogs as part of the
> debugging process, while my position is that the typical problem for which
> such lists are used is not "map a commit to the named entities modified in
> that change" but the inverse problem "map a named entity to the commits
> changing it", which version control tools handle well without needing to
> go via the ChangeLog-format lists at all.
Having the list of changed entities in the logs is now a just a
recommendation; the text describes the advantages of having that, but
it doesn't insist. Please check out the latest text (maybe it is
still only in CVS, not on prep, I don't keep track of that).
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-12 18:27 ` Eli Zaretskii
@ 2021-01-12 18:40 ` Eli Zaretskii
0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2021-01-12 18:40 UTC (permalink / raw)
To: joseph; +Cc: gdb-patches
> Date: Tue, 12 Jan 2021 20:27:40 +0200
> From: Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>
> Cc: gdb-patches@sourceware.org
>
> Please check out the latest text (maybe it is still only in CVS, not
> on prep, I don't keep track of that).
Actually, I now see that the version on prep is also up-to-date with
those changes.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-12 10:47 ` Andrew Burgess
2021-01-12 18:14 ` Joseph Myers
@ 2021-01-12 21:22 ` Mike Frysinger
2021-03-09 5:51 ` Mike Frysinger
2 siblings, 0 replies; 21+ messages in thread
From: Mike Frysinger @ 2021-01-12 21:22 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]
On 12 Jan 2021 10:47, Andrew Burgess wrote:
> * Mike Frysinger <vapier@gentoo.org> [2021-01-11 14:38:30 -0500]:
> > On 11 Jan 2021 12:00, Simon Marchi wrote:
> > > On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
> > > > I think sim/ should follow the same policy as gdb/ for now. Do feel
> > > > free to raise this as a suggestion for gdb/ in general though, it
> > > > would be an interesting conversation to observe.
> > >
> > > Last time I tried the gitlog-to-changelog script on GDB, it produced
> > > horrible results. Probably because it was not designed for C++.
> > >
> > > Making a script to produce ChangeLogs for C code is already very
> > > difficult, making it work with good results for C++ would be even
> > > worst. And most importantly, I think it would be wasted development
> > > time.
> >
> > to be clear, it isn't generating entries exactly like we write. it's
> > using the git commit logs with formatted dates. so i don't think this
> > applies exactly anymore. so it's inline with the GNU's VCS principles:
> > https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> > (and that also recommends just using gitlog-to-changelog).
>
> I read this page, and especially the part that talks about using
> gitlog-to-changelog, and I don't find their argument compelling.
>
> Early in the page they list some uses for ChangeLogs, which basically
> boils down to performing "software forensics". Their benefits are all
> good, but IMHO are all covered (and covered better) by what the VCS
> provide.
>
> At the end of the page they say if you don't maintain a ChangeLog then
> use a script to generate one in case people want to look at the
> ChangeLog. But they fail to explain what use a ChangeLog is in a
> release tree. The same argument could just as easily be used to
> justify including a poem in the release; it should be there in case
> someone wants to look at it.
>
> For me the question is what benefit does a ChangeLog offer in a
> release tree? When I look through the 7 points (in favour of
> ChangeLogs) raised on the above page I don't see what value any of
> those things have given only a release tree.
>
> If we really wanted to include something informative inside each
> release then I'd be most tempted to just do something like:
>
> git log --stat last-release-tag...new-release-tag > GIT-LOG
>
> That would give people a far more detailed understanding of what has
> changed.
the current gitlog-to-changelog script that my patches here use does
generate a file akin to what you're recommending with GIT-LOG (albeit
without --stat).
> But honestly, I don't think it's unreasonable to say that if someone
> wants to dig into the source history, just clone the repo.... and let
> ChangeLogs burn!
i don't have a problem with dumping `git log` to ChangeLog files as
part of the release tarball creation. i know we're all pretty well
integrated with the source repos and know how to find this info, but
sometimes people who download these releases are not. there is also
the slight angle of network connectivity not being as ubiquitous for
all users around the world as it might be for you & i.
but really my only very strong preference is to not ever have to
write another ChangeLog entry by hand, whether it be in the files
themselves, or inlined in the commit message, or attached to an
e-mail sent to the list. i can take/leave every other idea.
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-12 18:14 ` Joseph Myers
2021-01-12 18:27 ` Eli Zaretskii
@ 2021-01-12 21:27 ` Mike Frysinger
1 sibling, 0 replies; 21+ messages in thread
From: Mike Frysinger @ 2021-01-12 21:27 UTC (permalink / raw)
To: Joseph Myers; +Cc: Andrew Burgess, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
On 12 Jan 2021 18:14, Joseph Myers wrote:
> On Tue, 12 Jan 2021, Andrew Burgess wrote:
> > > to be clear, it isn't generating entries exactly like we write. it's
> > > using the git commit logs with formatted dates. so i don't think this
> > > applies exactly anymore. so it's inline with the GNU's VCS principles:
> > > https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> > > (and that also recommends just using gitlog-to-changelog).
> >
> > I read this page, and especially the part that talks about using
> > gitlog-to-changelog, and I don't find their argument compelling.
>
> What the GNU Coding Standards say about ChangeLogs isn't what would make
> sense from a starting point of modern development practices, it's what we
> could convince the maintainers of the GNU Coding Standards (being used to
> ChangeLog-centric development practices) to allow.
>
> The discussion started at
> <https://lists.gnu.org/archive/html/bug-standards/2017-07/msg00000.html>
> and took a few years (a few bits were on an internal GNU Project list, but
> most was on bug-standards). In particular, the maintainers of the GNU
> Coding Standards fixated on a point that they were used to using the lists
> of changes to named entities (functions etc.) in ChangeLogs as part of the
> debugging process, while my position is that the typical problem for which
> such lists are used is not "map a commit to the named entities modified in
> that change" but the inverse problem "map a named entity to the commits
> changing it", which version control tools handle well without needing to
> go via the ChangeLog-format lists at all.
thanks for the background info. tbh, i'm just trying to find any authority
that i can appeal to to help convince people to autogenerate things and not
require manual creation :).
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 1/3] src-release: fix indentation
2021-01-10 3:37 [PATCH 1/3] src-release: fix indentation Mike Frysinger
2021-01-10 3:37 ` [PATCH 2/3] gnulib: import gitlog-to-changelog Mike Frysinger
2021-01-10 3:42 ` [PATCH] sim: switch to autogenerated ChangeLog files Mike Frysinger
@ 2021-01-12 23:20 ` Mike Frysinger
2 siblings, 0 replies; 21+ messages in thread
From: Mike Frysinger @ 2021-01-12 23:20 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
On 09 Jan 2021 22:37, Mike Frysinger via Gdb-patches wrote:
> The indentation of the body of the nested statements got out of sync
> leading to the entire function being indented incorrectly and looking
> like it's part of the for loop.
>
> * src-release.sh (do_proto_toplev): Rewrite indentation.
i've pushed this patch as an obvious fix
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-01-12 10:47 ` Andrew Burgess
2021-01-12 18:14 ` Joseph Myers
2021-01-12 21:22 ` Mike Frysinger
@ 2021-03-09 5:51 ` Mike Frysinger
2021-03-09 9:42 ` Andrew Burgess
2 siblings, 1 reply; 21+ messages in thread
From: Mike Frysinger @ 2021-03-09 5:51 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
On 12 Jan 2021 10:47, Andrew Burgess wrote:
> Mike Frysinger <vapier@gentoo.org> [2021-01-11 14:38:30 -0500]:
> > On 11 Jan 2021 12:00, Simon Marchi wrote:
> > > On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
> > > > I think sim/ should follow the same policy as gdb/ for now. Do feel
> > > > free to raise this as a suggestion for gdb/ in general though, it
> > > > would be an interesting conversation to observe.
> > >
> > > Last time I tried the gitlog-to-changelog script on GDB, it produced
> > > horrible results. Probably because it was not designed for C++.
> > >
> > > Making a script to produce ChangeLogs for C code is already very
> > > difficult, making it work with good results for C++ would be even
> > > worst. And most importantly, I think it would be wasted development
> > > time.
> >
> > to be clear, it isn't generating entries exactly like we write. it's
> > using the git commit logs with formatted dates. so i don't think this
> > applies exactly anymore. so it's inline with the GNU's VCS principles:
> > https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> > (and that also recommends just using gitlog-to-changelog).
>
> I read this page, and especially the part that talks about using
> gitlog-to-changelog, and I don't find their argument compelling.
>
> Early in the page they list some uses for ChangeLogs, which basically
> boils down to performing "software forensics". Their benefits are all
> good, but IMHO are all covered (and covered better) by what the VCS
> provide.
>
> At the end of the page they say if you don't maintain a ChangeLog then
> use a script to generate one in case people want to look at the
> ChangeLog. But they fail to explain what use a ChangeLog is in a
> release tree. The same argument could just as easily be used to
> justify including a poem in the release; it should be there in case
> someone wants to look at it.
>
> For me the question is what benefit does a ChangeLog offer in a
> release tree? When I look through the 7 points (in favour of
> ChangeLogs) raised on the above page I don't see what value any of
> those things have given only a release tree.
>
> If we really wanted to include something informative inside each
> release then I'd be most tempted to just do something like:
>
> git log --stat last-release-tag...new-release-tag > GIT-LOG
>
> That would give people a far more detailed understanding of what has
> changed.
>
> But honestly, I don't think it's unreasonable to say that if someone
> wants to dig into the source history, just clone the repo.... and let
> ChangeLogs burn!
so how are we feeling now ? i think we agree that we don't want to hand
maintain ChangeLog files.
then we need to decide on whether we want to include ChangeLog files for
sim/ at all in releases. i'd be fine with just dropping them entirely if
we don't want to bikeshed it anymore. we can create a sim/ChangeLog that
just reads:
Please see the git log online at:
https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=sim
if we do include them, i think it's reasonable to expect they take a form
similar to the other ChangeLog files in the tree. that would mean using
gitlog-to-changelog, or some other gnu tool that i've missed. the upside
to that over a raw `git log` is that, for old commits, it wil extract any
ChangeLog entries and inline them in the log. this would be an easy way
to bridge the old & new ways of writing log entries.
-mike
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-03-09 5:51 ` Mike Frysinger
@ 2021-03-09 9:42 ` Andrew Burgess
2021-03-17 14:22 ` Luis Machado
0 siblings, 1 reply; 21+ messages in thread
From: Andrew Burgess @ 2021-03-09 9:42 UTC (permalink / raw)
To: gdb-patches
* Mike Frysinger <vapier@gentoo.org> [2021-03-09 00:51:15 -0500]:
> On 12 Jan 2021 10:47, Andrew Burgess wrote:
> > Mike Frysinger <vapier@gentoo.org> [2021-01-11 14:38:30 -0500]:
> > > On 11 Jan 2021 12:00, Simon Marchi wrote:
> > > > On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
> > > > > I think sim/ should follow the same policy as gdb/ for now. Do feel
> > > > > free to raise this as a suggestion for gdb/ in general though, it
> > > > > would be an interesting conversation to observe.
> > > >
> > > > Last time I tried the gitlog-to-changelog script on GDB, it produced
> > > > horrible results. Probably because it was not designed for C++.
> > > >
> > > > Making a script to produce ChangeLogs for C code is already very
> > > > difficult, making it work with good results for C++ would be even
> > > > worst. And most importantly, I think it would be wasted development
> > > > time.
> > >
> > > to be clear, it isn't generating entries exactly like we write. it's
> > > using the git commit logs with formatted dates. so i don't think this
> > > applies exactly anymore. so it's inline with the GNU's VCS principles:
> > > https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> > > (and that also recommends just using gitlog-to-changelog).
> >
> > I read this page, and especially the part that talks about using
> > gitlog-to-changelog, and I don't find their argument compelling.
> >
> > Early in the page they list some uses for ChangeLogs, which basically
> > boils down to performing "software forensics". Their benefits are all
> > good, but IMHO are all covered (and covered better) by what the VCS
> > provide.
> >
> > At the end of the page they say if you don't maintain a ChangeLog then
> > use a script to generate one in case people want to look at the
> > ChangeLog. But they fail to explain what use a ChangeLog is in a
> > release tree. The same argument could just as easily be used to
> > justify including a poem in the release; it should be there in case
> > someone wants to look at it.
> >
> > For me the question is what benefit does a ChangeLog offer in a
> > release tree? When I look through the 7 points (in favour of
> > ChangeLogs) raised on the above page I don't see what value any of
> > those things have given only a release tree.
> >
> > If we really wanted to include something informative inside each
> > release then I'd be most tempted to just do something like:
> >
> > git log --stat last-release-tag...new-release-tag > GIT-LOG
> >
> > That would give people a far more detailed understanding of what has
> > changed.
> >
> > But honestly, I don't think it's unreasonable to say that if someone
> > wants to dig into the source history, just clone the repo.... and let
> > ChangeLogs burn!
>
> so how are we feeling now ? i think we agree that we don't want to hand
> maintain ChangeLog files.
>
> then we need to decide on whether we want to include ChangeLog files for
> sim/ at all in releases. i'd be fine with just dropping them entirely if
> we don't want to bikeshed it anymore. we can create a sim/ChangeLog that
> just reads:
> Please see the git log online at:
> https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=sim
>
> if we do include them, i think it's reasonable to expect they take a form
> similar to the other ChangeLog files in the tree. that would mean using
> gitlog-to-changelog, or some other gnu tool that i've missed. the upside
> to that over a raw `git log` is that, for old commits, it wil extract any
> ChangeLog entries and inline them in the log. this would be an easy way
> to bridge the old & new ways of writing log entries.
My general position is that sim/ is really a sub-component of gdb, as
it is only ever released as part of gdb, and as such should follow GDB
policies and coding standards, just for consistency.
That said, ChangeLogs suck so much, so maybe we could use this as an
opportunity to drop them, and maybe set some precedent for changing
gdb/ one day (hey, I can dream!).
I think the one thing I would say is that auto-generated ChangeLogs
are worse than what we currently have, so can we please agree to take
them off the table. I've not yet seen a tool that can 100% accurately
figure out the names for changed entities, nor does an auto-generated
script ever say anything useful about what changed. So you're left
with a list of things that _might_ have changed, with no information
about _what_ changed in them. Just a complete waste of time.
I guess the one thing that has surprised me is that nobody has jumped
in to really defend ChangeLogs. Maybe there really is hope that we
could drop these for gdb/...
I think you should create a new top-level post, with a subject line
that makes it clear you're planning to drop ChangeLogs for sim/. If
nobody complains to that then go with your plan, just point folk to
the online history.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] sim: switch to autogenerated ChangeLog files
2021-03-09 9:42 ` Andrew Burgess
@ 2021-03-17 14:22 ` Luis Machado
0 siblings, 0 replies; 21+ messages in thread
From: Luis Machado @ 2021-03-17 14:22 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches, Mike Frysinger
On 3/9/21 6:42 AM, Andrew Burgess wrote:
> * Mike Frysinger <vapier@gentoo.org> [2021-03-09 00:51:15 -0500]:
>
>> On 12 Jan 2021 10:47, Andrew Burgess wrote:
>>> Mike Frysinger <vapier@gentoo.org> [2021-01-11 14:38:30 -0500]:
>>>> On 11 Jan 2021 12:00, Simon Marchi wrote:
>>>>> On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
>>>>>> I think sim/ should follow the same policy as gdb/ for now. Do feel
>>>>>> free to raise this as a suggestion for gdb/ in general though, it
>>>>>> would be an interesting conversation to observe.
>>>>>
>>>>> Last time I tried the gitlog-to-changelog script on GDB, it produced
>>>>> horrible results. Probably because it was not designed for C++.
>>>>>
>>>>> Making a script to produce ChangeLogs for C code is already very
>>>>> difficult, making it work with good results for C++ would be even
>>>>> worst. And most importantly, I think it would be wasted development
>>>>> time.
>>>>
>>>> to be clear, it isn't generating entries exactly like we write. it's
>>>> using the git commit logs with formatted dates. so i don't think this
>>>> applies exactly anymore. so it's inline with the GNU's VCS principles:
>>>> https://www.gnu.org/prep/standards/html_node/Change-Logs.html
>>>> (and that also recommends just using gitlog-to-changelog).
>>>
>>> I read this page, and especially the part that talks about using
>>> gitlog-to-changelog, and I don't find their argument compelling.
>>>
>>> Early in the page they list some uses for ChangeLogs, which basically
>>> boils down to performing "software forensics". Their benefits are all
>>> good, but IMHO are all covered (and covered better) by what the VCS
>>> provide.
>>>
>>> At the end of the page they say if you don't maintain a ChangeLog then
>>> use a script to generate one in case people want to look at the
>>> ChangeLog. But they fail to explain what use a ChangeLog is in a
>>> release tree. The same argument could just as easily be used to
>>> justify including a poem in the release; it should be there in case
>>> someone wants to look at it.
>>>
>>> For me the question is what benefit does a ChangeLog offer in a
>>> release tree? When I look through the 7 points (in favour of
>>> ChangeLogs) raised on the above page I don't see what value any of
>>> those things have given only a release tree.
>>>
>>> If we really wanted to include something informative inside each
>>> release then I'd be most tempted to just do something like:
>>>
>>> git log --stat last-release-tag...new-release-tag > GIT-LOG
>>>
>>> That would give people a far more detailed understanding of what has
>>> changed.
>>>
>>> But honestly, I don't think it's unreasonable to say that if someone
>>> wants to dig into the source history, just clone the repo.... and let
>>> ChangeLogs burn!
>>
>> so how are we feeling now ? i think we agree that we don't want to hand
>> maintain ChangeLog files.
>>
>> then we need to decide on whether we want to include ChangeLog files for
>> sim/ at all in releases. i'd be fine with just dropping them entirely if
>> we don't want to bikeshed it anymore. we can create a sim/ChangeLog that
>> just reads:
>> Please see the git log online at:
>> https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=sim
>>
>> if we do include them, i think it's reasonable to expect they take a form
>> similar to the other ChangeLog files in the tree. that would mean using
>> gitlog-to-changelog, or some other gnu tool that i've missed. the upside
>> to that over a raw `git log` is that, for old commits, it wil extract any
>> ChangeLog entries and inline them in the log. this would be an easy way
>> to bridge the old & new ways of writing log entries.
>
> My general position is that sim/ is really a sub-component of gdb, as
> it is only ever released as part of gdb, and as such should follow GDB
> policies and coding standards, just for consistency.
>
> That said, ChangeLogs suck so much, so maybe we could use this as an
> opportunity to drop them, and maybe set some precedent for changing
> gdb/ one day (hey, I can dream!).
>
> I think the one thing I would say is that auto-generated ChangeLogs
> are worse than what we currently have, so can we please agree to take
> them off the table. I've not yet seen a tool that can 100% accurately
> figure out the names for changed entities, nor does an auto-generated
> script ever say anything useful about what changed. So you're left
> with a list of things that _might_ have changed, with no information
> about _what_ changed in them. Just a complete waste of time.
>
> I guess the one thing that has surprised me is that nobody has jumped
> in to really defend ChangeLogs. Maybe there really is hope that we
> could drop these for gdb/...
My guess is that there are only a few active developers in the GDB
community that care about ChangeLog files. Most of us suffer in silence
wasting valuable time writing less-than-useful ChangeLog entries, hoping
one day there will be a discussion on their usefulness right now.
It has gotten worse with C++, because now the names tend to be longer
and we start hitting the 80 columns limit as well. So sometimes we need
to solve puzzles and fit things properly into the given limits.
Isn't this something we can discuss more broadly in the context of the
GDB community/development roadmap as a whole?
I'm not sure what group of people decides that there's been enough
discussion and bikeshedding to make a decision. FSF maintainers? Global
maintainers? Or will a consensus-based decision (like glibc) suffice?
>
> I think you should create a new top-level post, with a subject line
> that makes it clear you're planning to drop ChangeLogs for sim/. If
> nobody complains to that then go with your plan, just point folk to
> the online history.
>
>
> Thanks,
> Andrew
>
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2021-03-17 14:22 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-10 3:37 [PATCH 1/3] src-release: fix indentation Mike Frysinger
2021-01-10 3:37 ` [PATCH 2/3] gnulib: import gitlog-to-changelog Mike Frysinger
2021-01-11 11:06 ` Andrew Burgess
2021-01-10 3:42 ` [PATCH] sim: switch to autogenerated ChangeLog files Mike Frysinger
2021-01-11 11:05 ` Andrew Burgess
2021-01-11 17:00 ` Simon Marchi
2021-01-11 17:10 ` Luis Machado
2021-01-11 17:31 ` Christian Biesinger
2021-01-11 19:38 ` Mike Frysinger
2021-01-11 19:54 ` Simon Marchi
2021-01-11 20:35 ` Mike Frysinger
2021-01-12 10:47 ` Andrew Burgess
2021-01-12 18:14 ` Joseph Myers
2021-01-12 18:27 ` Eli Zaretskii
2021-01-12 18:40 ` Eli Zaretskii
2021-01-12 21:27 ` Mike Frysinger
2021-01-12 21:22 ` Mike Frysinger
2021-03-09 5:51 ` Mike Frysinger
2021-03-09 9:42 ` Andrew Burgess
2021-03-17 14:22 ` Luis Machado
2021-01-12 23:20 ` [PATCH 1/3] src-release: fix indentation Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).