GNOME Bugzilla – Bug 579279
Support generating ChangeLog from git log
Last modified: 2015-02-05 11:45:56 UTC
With the git migration, many modules are switching from ChangeLog to git checkint commits, with an autogenerated ChangeLog on make dist. We should add a GNOME_CHANGELOG macro that would AC_SUBST a makefile fragment that one can then simply use in the toplevel Makefile.am to create the ChangeLog.
I guess Behdad's work is a good first step. Is there anything missing in it? :-)
Created attachment 133588 [details] [review] Add ChangeLog support to gnome-common
+ GNOME_CHANGELOG_RULE="dist-hook: @if test -d \"$(srcdir)/.git\"; \ A newline and a tab char is needed after "dist-hook:".
We could also use "--after" or "--since" and be able to pass dates instead of revisions.
Created attachment 134068 [details] [review] Add ChangeLog support to gnome-common (updated) I've re-done the patch so that it defines a "ChangeLog" rule, allowing people to keep their own dist-hook rules without conflicts. "ChangeLog" can then be added to EXTRA_DIST. This also fixes Behdad's comments about the rule formatting, since I've brushed up a bit on my autofoo. I don't think there's any point in implementing --after or --since support, since there could be ambiguity as to which commit on that day you mean, and it's not that big a deal to pass a commit ID in; the rule's going to be put in people's Makefiles once, and left alone for ever more afterwards.
This doesn't seem to work like comment 5 says: I added this patch, then added GNOME_CHANGELOG in configure, @GNOME_CHANGELOG_RULE@ to Makefile.am and ChangeLog to EXTRA_DIST, but "make dist" fails: Creating ChangeLog { test ! -d gnome-common-2.27.0 || { find gnome-common-2.27.0 -type d ! -perm -200 -exec chmod u+w {} ';' && rm -fr gnome-common-2.27.0; }; } test -d gnome-common-2.27.0 || mkdir gnome-common-2.27.0 cp: cannot stat `./ChangeLog': No such file or directory make: *** [distdir] Error 1 Using dist-hook: ChangeLog instead of the EXTRA_DIST works, however.
(In reply to comment #6) > This doesn't seem to work like comment 5 says: I added this patch, then added > GNOME_CHANGELOG in configure, @GNOME_CHANGELOG_RULE@ to Makefile.am and > ChangeLog to EXTRA_DIST, but "make dist" fails: > > Creating ChangeLog > { test ! -d gnome-common-2.27.0 || { find gnome-common-2.27.0 -type d ! -perm > -200 -exec chmod u+w {} ';' && rm -fr gnome-common-2.27.0; }; } > test -d gnome-common-2.27.0 || mkdir gnome-common-2.27.0 > cp: cannot stat `./ChangeLog': No such file or directory > make: *** [distdir] Error 1 > > Using > > dist-hook: ChangeLog > > instead of the EXTRA_DIST works, however. You're totally right. I had a pre-existing ChangeLog hanging around from previous tests when I ran the tests on this new patch version, which caused EXTRA_DIST to work.
I guess what I wanted to ask was whether this dist-hook thing is the best we can do, or if we can simplify this somehow. I.e. can we just put that dist-hook in the GNOME_CHANGELOG_RULE macro too? And will this interfere with another dist-hook that the app may want to use in the same Makefile.am ?
(In reply to comment #8) > I guess what I wanted to ask was whether this dist-hook thing is the best we > can do, or if we can simplify this somehow. I.e. can we just put that dist-hook > in the GNOME_CHANGELOG_RULE macro too? And will this interfere with another > dist-hook that the app may want to use in the same Makefile.am ? automake would give warnings about redefining rules if we put the dist-hook in the GNOME_CHANGELOG_RULE macro.
It's fine if we just add deps though. That is, if the macro expands to: disthook: create-changelog create-changelog: @actually generate changelog... .PHONY: create-changelog That said, I'm really leaning towards making ChangeLog in the srcdir and normally distribute it. Before every release I find myself doing "make ChangeLog", then review the changelog and write NEWS entries. This also allows me to review the ChangeLog that will go into the tarball. As opposed to "make dist", then unroll the tarball and check inside...
(In reply to comment #10) > That said, I'm really leaning towards making ChangeLog in the srcdir and > normally distribute it. Before every release I find myself doing "make > ChangeLog", then review the changelog and write NEWS entries. This also allows > me to review the ChangeLog that will go into the tarball. As opposed to "make > dist", then unroll the tarball and check inside... There's nothing stopping you from calling `make ChangeLog` before `make dist` at the moment, though.
(In reply to comment #10) > That said, I'm really leaning towards making ChangeLog in the srcdir and I'd prefer that, too; except that since it's created by make, it belongs in builddir, not srcdir. And that's how I have things set up in my modules, e.g. gnome-terminal, gucharmap.
(In reply to comment #11) > (In reply to comment #10) > > That said, I'm really leaning towards making ChangeLog in the srcdir and > > normally distribute it. Before every release I find myself doing "make > > ChangeLog", then review the changelog and write NEWS entries. This also allows > > me to review the ChangeLog that will go into the tarball. As opposed to "make > > dist", then unroll the tarball and check inside... > > There's nothing stopping you from calling `make ChangeLog` before `make dist` > at the moment, though. Right. I prefer this method over the one documented on the wiki that creates ChangeLog direction in the dist dir.
(In reply to comment #12) > (In reply to comment #10) > > That said, I'm really leaning towards making ChangeLog in the srcdir and > > I'd prefer that, too; except that since it's created by make, it belongs in > builddir, not srcdir. And that's how I have things set up in my modules, e.g. > gnome-terminal, gucharmap. I'm very confident that there is a "make distcheck" problem with doing it like that. "make distcheck" checks that after a "distclean", no files are left in the build dir. So, the ChangeLog will fail that test unless you remove it in "distclean", which is obviously wrong since we want to distribute the ChangeLog. That's why in my packages (pango, cairo, ...) I build it in the srcdir.
As reference, here the mm-common solution: http://git.gnome.org/cgit/mm-common/tree/build/dist-changelog.am
Philip and I agree that this should not be in gnome-common, but instead upsteram in the autoconf archive. Leaving the bug open so that we can track the upstreaming.
(In reply to comment #16) > Philip and I agree that this should not be in gnome-common, but instead > upsteram in the autoconf archive. Leaving the bug open so that we can track the > upstreaming. => https://github.com/pwithnall/autoconf-archive/tree/ax-generate-changelog How about this? I think it addresses all the above comments, though I could have missed something. It generates in $(top_distdir) on dist-hook, and is used as: configure.ac: AX_GENERATE_CHANGELOG() Makefile.am: @GENERATE_CHANGELOG_RULES@ CHANGELOG_START = my-reflog^ Based on the rules from Cheese, with bits of the other rules mixed in too.
I’d quite like to submit this to autoconf-archive soon so we can finish off deprecating gnome-common. If anybody has any feedback, please can you let me know in the next two days? Thanks!
We discussed this briefly on IRC. It seems that an empty dist-hook rule is required in Makefile.am in order to trigger the ChangeLog generation during dist.
(In reply to comment #19) > We discussed this briefly on IRC. It seems that an empty dist-hook rule is > required in Makefile.am in order to trigger the ChangeLog generation during > dist. Yeah, it appears I tested in a module which had a dist-hook defined separately. I need to find time to beat automake into submission, so please hold off on reviews until then. Sorry. :-(
Looks like the only way to do it is to add the dist-hook prerequisite in Makefile.am rather than in the macro. Bit of a pain. You now have to add: dist-hook: dist-ChangeLog Reviews welcome: https://github.com/pwithnall/autoconf-archive/tree/ax-generate-changelog
Works fine for me with that change. Read for submission to the autoconf archive, I would say!
Merged in the autoconf archive: https://github.com/peti/autoconf-archive/commit/589dbb756e0463a4177a7e63d247a52396af187a Thanks Philip!