Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

[Arne Babenhauserheide (IMK)]

Dear GNU Hackers,


In quite a few guides I saw people suggest using the foreign autoconf
style to avoid having to create the required text files.

The goal of this email is to get more people to use the GNU style, so
the interface for understanding an autotools project becomes more
consistent again: GNU style should become standard for all guides.


Among the required files, NEWS is easy to create but cannot be guessed
automatically because it is intended for humans, and README is becoming
standard (again) due to most code hosting sites using it as the summary
page. AUTHORS and ChangeLog normally only contain information which
already available in most version tracking systems - and can be created
easily from that.

If autotools did this automatically, the barrier for using GNU style in
the autotools with a version tracking system would be much smaller: Just
write README and NEWS.


I initially planned to just send a small example script, but that
matured faster than I had expected, so you can now find it at


https://bitbucket.org/ArneBab/autochangelog/src/tip/create-or-update-changelog-and-authors.sh

If someone with git-foo could cleanup the git ChangeLog creation to
conform with the GNU ChangeLog standard, that script should be a good
working example.

The script only touches files which were created by the script or are
missing.


Best wishes,
Arne
--
Doktorand
Gruppe: GHG

Raum: 435/410
Tel.: [phone]
***@kit.edu

Karlsruher Institut fÃŒr Technologie
IMK-ASF
Postfach 36 40
76021 Karlsruhe

[Eric Blake]

Post by Arne Babenhauserheide (IMK)
Dear GNU Hackers,
In quite a few guides I saw people suggest using the foreign autoconf
style to avoid having to create the required text files.

s/foreign autoconf/foreign automake/

Not necessary. Coreutils is an example project that uses the standard
gnu level rather than the weaker foreign level, while still using a
ChangeLog generated from git rather than maintained by hand. It uses
the gnulib script build-aux/gitlog-to-changelog to create the real
ChangeLog at 'make dist' time, plus a bootstrap script that does 'touch
ChangeLog' prior to calling automake, to keep automake happy for
developers. The gitlog-to-changelog script also includes a mechanism
for touching up mistakes in the git log (such as spelling corrections or
incorrect attributions) so that you don't have to rewrite git history to
make corrections. It also has rules for generating THANKS (rather than
AUTHORS) from git history.

Post by Arne Babenhauserheide (IMK)
If autotools did this automatically, the barrier for using GNU style in
the autotools with a version tracking system would be much smaller: Just
write README and NEWS.

autoconf can't do this automatically, but gnulib can.

[Arne Babenhauserheide (IMK)]

Hi Eric,

Post by Eric Blake

Post by Arne Babenhauserheide (IMK)
In quite a few guides I saw people suggest using the foreign autoconf
style to avoid having to create the required text files.

s/foreign autoconf/foreign automake/

Ah, yes. I think I misguessed the project, because the style is defined
in the configure.ac.

I saw the gnulib script, but do not see how this is an argument
*against* auto-generating the ChangeLog when it isn’t available.

It rather looks like like integrating this as default behavior would
make it unnecessary to patch around autotools requirements. People
obviously already want that functionality.

Post by Eric Blake

Post by Arne Babenhauserheide (IMK)
If autotools did this automatically, the barrier for using GNU style in
the autotools with a version tracking system would be much smaller: Just
write README and NEWS.

autoconf can't do this automatically, but gnulib can.

Why *can’t* autoconf or automake do this automatically?

Best wishes,
Arne
--
Doktorand
Gruppe: GHG

Raum: 435/410
Tel.: [phone]
***@kit.edu

Karlsruher Institut fÃŒr Technologie
IMK-ASF
Postfach 36 40
76021 Karlsruhe

[Eric Blake]

Post by Arne Babenhauserheide (IMK)

Post by Eric Blake

Post by Arne Babenhauserheide (IMK)
If autotools did this automatically, the barrier for using GNU style in
the autotools with a version tracking system would be much smaller: Just
write README and NEWS.

autoconf can't do this automatically, but gnulib can.

Why *can’t* autoconf or automake do this automatically?

Autoconf has never required NEWS, AUTHORS, or ChangeLog - that has
always been automake's domain. So asking on this list is not the best
place. It may be worth asking automake if they are willing to automate
some of the steps that coreutils and other projects are currently
getting via gnulib. On the other hand, since gnulib already does a good
job of it, why should any other project duplicate the efforts?

[Arne Babenhauserheide (IMK)]

Post by Eric Blake

Post by Arne Babenhauserheide (IMK)

Post by Eric Blake

Post by Arne Babenhauserheide (IMK)
If autotools did this automatically, the barrier for using GNU style in
the autotools with a version tracking system would be much smaller: Just
write README and NEWS.

autoconf can't do this automatically, but gnulib can.

Why *can’t* autoconf or automake do this automatically?

Autoconf has never required NEWS, AUTHORS, or ChangeLog - that has
always been automake's domain. So asking on this list is not the best
place. It may be worth asking automake if they are willing to automate
some of the steps that coreutils and other projects are currently
getting via gnulib. On the other hand, since gnulib already does a good
job of it, why should any other project duplicate the efforts?

Ah, OK. I misunderstood you (it sounded to me like you meant that this
should not be done) - I’ll ask at the automake list.

Why shouldn’t the Automake folks just reuse the work done by gnulib?
Both are GNU projects. The advantage would be, that any project using
automake would get the benefit without having to take additional steps.

It would be *standard*.

Best wishes - and thanks for your answers!
Arne
--
Doktorand
Gruppe: GHG

Raum: 435/410
Tel.: [phone]
***@kit.edu

Karlsruher Institut fÃŒr Technologie
IMK-ASF
Postfach 36 40
76021 Karlsruhe