"subscribe LISTNAME"
"subscribe LISTNAME"
Emacs ChangeLog generation and commit messages
Emacs has a very useful facility. You press “C-x 4 a” in a place where you make changes, and the editor automatically opens the right ChangeLog file and adds a draft entry to it, like this: 2023-11-06 Florian Weimer * c-opts.cc (c_common_post_options): █ Is there something like this that works with commit messages and produces output compatible with GCC's expectations? Thanks, Florian
Re: Emacs ChangeLog generation and commit messages
On Mon, Nov 06, 2023 at 05:38:40PM +0100, Florian Weimer via Gcc wrote: > Emacs has a very useful facility. You press “C-x 4 a” in a place where > you make changes, and the editor automatically opens the right ChangeLog > file and adds a draft entry to it, like this: > > 2023-11-06 Florian Weimer > > * c-opts.cc (c_common_post_options): █ > > Is there something like this that works with commit messages and > produces output compatible with GCC's expectations? contrib/mklog.py ? Jakub
Re: Emacs ChangeLog generation and commit messages
On Mon, Nov 6, 2023 at 8:39 AM Florian Weimer via Gcc wrote: > > Emacs has a very useful facility. You press “C-x 4 a” in a place where > you make changes, and the editor automatically opens the right ChangeLog > file and adds a draft entry to it, like this: > > 2023-11-06 Florian Weimer > > * c-opts.cc (c_common_post_options): █ > > Is there something like this that works with commit messages and > produces output compatible with GCC's expectations? Yes contrib/git-commit-mklog.py . Which can also be used directly with git if you run `contrib/gcc-git-customization.sh`. This will install an alias so you can just do `git gcc-commit-mklog ` and you will get a commit log with that part filled in. Thanks, Andrew > > Thanks, > Florian >
Checks that autotools generated files were re-generated correctly
Hello, I have inherited Martin Liška's buildbot script that checks that all sorts of autotools generated files, mainly configure scripts, were re-generated correctly when appropriate. While the checks are hopefully useful, they report issues surprisingly often and reporting them feels especially unproductive. Could such checks be added to our server side push hooks so that commits introducing these breakages would get refused automatically. While the check might be a bit expensive, it only needs to be run on files touching the generated files and/or the files these are generated from. Alternatively, Maxim, you seem to have an infrastructure that is capable of sending email. Would you consider adding the check to your buildbot instance and report issues automatically? The level of totally false-positives should be low (I thought zero but see https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635358.html). Thanks for any ideas which can lead to a mostly automated process. Martin
Re: Checks that autotools generated files were re-generated correctly
Hi! On Mon, 6 Nov 2023 at 18:05, Martin Jambor wrote: > > Hello, > > I have inherited Martin Liška's buildbot script that checks that all > sorts of autotools generated files, mainly configure scripts, were > re-generated correctly when appropriate. While the checks are hopefully > useful, they report issues surprisingly often and reporting them feels > especially unproductive. > > Could such checks be added to our server side push hooks so that commits > introducing these breakages would get refused automatically. While the > check might be a bit expensive, it only needs to be run on files > touching the generated files and/or the files these are generated from. > > Alternatively, Maxim, you seem to have an infrastructure that is capable > of sending email. Would you consider adding the check to your buildbot > instance and report issues automatically? The level of totally After the discussions we had during Cauldron, I actually thought we should add such a bot. Initially I was thinking about adding this as a "precommit" check, to make sure the autogenerated files were submitted correctly, but I realized that the policy is actually not to send autogenerated files as part of the patch (thus making pre-commit check impracticable in such cases, unless we autogenerate those files after applying the patch) I understand you mean to run this as a post-commit bot, meaning we would continue to "accept" broken commits, but now automatically send a notification, asking for a prompt fix? We can probably implement that, indeed. Is that the general agreement? Thanks, Christophe > false-positives should be low (I thought zero but see > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635358.html). > > Thanks for any ideas which can lead to a mostly automated process. > > Martin
Re: Emacs ChangeLog generation and commit messages
Hello,
On Mon, Nov 06 2023, Florian Weimer via Gcc wrote:
> Emacs has a very useful facility. You press “C-x 4 a” in a place where
> you make changes, and the editor automatically opens the right ChangeLog
> file and adds a draft entry to it, like this:
>
> 2023-11-06 Florian Weimer
>
> * c-opts.cc (c_common_post_options): █
>
> Is there something like this that works with commit messages and
> produces output compatible with GCC's expectations?
>
I use exactly this. But I modify it to write the ChangeLog to file
ChangeLog.mine instead:
(setq change-log-default-name "ChangeLog.mine")
Then in a git prepare-commit-msg hook I gather these:
--
#!/bin/bash
#
# Hook script to prepare the commit log message from the first
# entry in each modified ChangeLog being committed.
set -e
# echo $1 $2 $3
COMMIT_MSG_FILE=$1
COMMIT_SOURCE=$2
SHA1=$3
# "merge" means the commit is a merge or a .git/MERGE_MSG file exists.
# "message" means a -m or -F option was given.
# "squash" means a .git/SQUASH_MSG file exists.
# "commit" means a -c, -C or --amend option was given (and $3 is commit SHA1).
case "$2," in
merge,|squash,) exit ;;
message,) exit ;;
esac
# If there is already a ChangeLog entry, assume --amend and exit
grep -q "ChangeLog" "$COMMIT_MSG_FILE" && exit 0
TMPF=$(mktemp)
echo > $TMPF
for I in `find . -name ChangeLog.mine -type f -size +0c | xargs`; do
echo >> $TMPF
CNF=`echo ${I%.mine} | cut -c3-` >> $TMPF
echo "${CNF}:" >> $TMPF
echo >> $TMPF
awk -v n=2 '/^2/{p++} p> $TMPF
done
echo >> $TMPF
cat $COMMIT_MSG_FILE >> $TMPF
mv $TMPF $COMMIT_MSG_FILE
--
The only downside is that you need to truncate the ChangeLog.mine files
at the appropriate time. The big upside is that you can generate
ChangeLog as you stage hunks in emacs magit.
Martin
Hhb bị in bị
Sent from my iPhone
Re: Checks that autotools generated files were re-generated correctly
> On Nov 6, 2023, at 21:19, Christophe Lyon wrote: > > Hi! > > On Mon, 6 Nov 2023 at 18:05, Martin Jambor wrote: >> >> Hello, >> >> I have inherited Martin Liška's buildbot script that checks that all >> sorts of autotools generated files, mainly configure scripts, were >> re-generated correctly when appropriate. While the checks are hopefully >> useful, they report issues surprisingly often and reporting them feels >> especially unproductive. >> >> Could such checks be added to our server side push hooks so that commits >> introducing these breakages would get refused automatically. While the >> check might be a bit expensive, it only needs to be run on files >> touching the generated files and/or the files these are generated from. >> >> Alternatively, Maxim, you seem to have an infrastructure that is capable >> of sending email. Would you consider adding the check to your buildbot >> instance and report issues automatically? The level of totally > > After the discussions we had during Cauldron, I actually thought we > should add such a bot. > > Initially I was thinking about adding this as a "precommit" check, to > make sure the autogenerated files were submitted correctly, but I > realized that the policy is actually not to send autogenerated files > as part of the patch (thus making pre-commit check impracticable in > such cases, unless we autogenerate those files after applying the > patch) > > I understand you mean to run this as a post-commit bot, meaning we > would continue to "accept" broken commits, but now automatically send > a notification, asking for a prompt fix? > > We can probably implement that, indeed. Is that the general agreement? [CC: Siddhesh, Carlos] Hi Martin, I agree with Christophe, and we can add various source-level checks and wrap them up as a post-commit job. The job will then send out email reports to developers whose patches failed it. Where the current script is located? These checks would be useful for all GNU Toolchain projects -- binutils/GDB, GCC, Glibc and, maybe, Newlib -- so it would be useful to put it in a separate "gnutools" repo. I think Siddhesh and Carlos are looking into creating such a repo on gitlab? Thanks, -- Maxim Kuvyrkov https://www.linaro.org
