After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 579279 - Support generating ChangeLog from git log
Support generating ChangeLog from git log
Status: RESOLVED NOTGNOME
Product: gnome-common
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: Gnome Common Maintainer(s)
Gnome Common Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-04-17 11:47 UTC by Christian Persch
Modified: 2015-02-05 11:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add ChangeLog support to gnome-common (1.94 KB, patch)
2009-04-29 18:11 UTC, Philip Withnall
none Details | Review
Add ChangeLog support to gnome-common (updated) (1.07 KB, patch)
2009-05-05 21:24 UTC, Philip Withnall
none Details | Review

Description Christian Persch 2009-04-17 11:47:59 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.
Comment 1 Vincent Untz 2009-04-21 02:45:33 UTC
I guess Behdad's work is a good first step. Is there anything missing in it? :-)
Comment 2 Philip Withnall 2009-04-29 18:11:29 UTC
Created attachment 133588 [details] [review]
Add ChangeLog support to gnome-common
Comment 3 Behdad Esfahbod 2009-04-29 18:45:55 UTC
+	GNOME_CHANGELOG_RULE="dist-hook: @if test -d \"$(srcdir)/.git\"; \

A newline and a tab char is needed after "dist-hook:".
Comment 4 Bastien Nocera 2009-04-29 19:25:30 UTC
We could also use "--after" or "--since" and be able to pass dates instead of revisions.
Comment 5 Philip Withnall 2009-05-05 21:24:49 UTC
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.
Comment 6 Christian Persch 2009-05-11 13:38:51 UTC
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.
Comment 7 Philip Withnall 2009-05-11 18:30:26 UTC
(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.
Comment 8 Christian Persch 2009-05-27 21:19:37 UTC
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 ?
Comment 9 Philip Withnall 2009-05-27 23:26:50 UTC
(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.
Comment 10 Behdad Esfahbod 2009-05-28 02:37:43 UTC
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...
Comment 11 Philip Withnall 2009-05-28 12:11:14 UTC
(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.
Comment 12 Christian Persch 2009-05-28 12:17:45 UTC
(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.
Comment 13 Behdad Esfahbod 2009-05-29 14:37:47 UTC
(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.


Comment 14 Behdad Esfahbod 2009-05-29 14:39:21 UTC
(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.
Comment 15 Javier Jardón (IRC: jjardon) 2009-10-30 01:39:06 UTC
As reference, here the mm-common solution: http://git.gnome.org/cgit/mm-common/tree/build/dist-changelog.am
Comment 16 David King 2015-01-26 15:15:52 UTC
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.
Comment 17 Philip Withnall 2015-01-31 20:31:59 UTC
(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.
Comment 18 Philip Withnall 2015-02-04 08:16:06 UTC
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!
Comment 19 David King 2015-02-04 14:22:29 UTC
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.
Comment 20 Philip Withnall 2015-02-04 17:12:07 UTC
(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. :-(
Comment 21 Philip Withnall 2015-02-04 22:37:49 UTC
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
Comment 22 David King 2015-02-05 08:53:40 UTC
Works fine for me with that change. Read for submission to the autoconf archive, I would say!
Comment 23 David King 2015-02-05 11:45:56 UTC
Merged in the autoconf archive:

https://github.com/peti/autoconf-archive/commit/589dbb756e0463a4177a7e63d247a52396af187a

Thanks Philip!