gnuify-changelog.pl problem in Roma source may apply to P5

Hi all, I did a quick bugfix for this ticket: <http://sourceforge.net/p/tei/bugs/724/> back in July, but I'm now dealing with the ramifications of getting it onto tei-c.org, and in the process, noticing that the project was moved from SF to GitHub without some key code changes being made to handle the changelog; I think the same issues will apply to P5, so I think we could use Roma as a good testcase for handling the change. When you run "make dist" or "make install" in the Roma source, one of the things that should happen is that the latest changes are added to the ChangeLog file. That's done by calling a PERL script called gnuify-changelog, which seems to be fairly widely used; but it is explicitly customized for the project and its contributors, all of whom are listed explicitly. What it does is to call svn log to get the latest commits, then converts them into a GNU-style changelog by substituting more detailed user info for user names. There are four problems with this: 1. gnuify-changelog.pl no longer exists in the Roma source, since it's been pulled out of the P5 tree. 2. We're now using git, not svn, so the log info is differently formatted. 3. The script requires a hard-coded list of contributors to be maintained. However, git log seems to be more friendly than svn log, in that it includes user name and email: --------------- $> git log -n 1 --name-status commit 18cc86ddcd79b409a9bfa406426fe4685c37fa8a Author: martindholmes <mholmes@uvic.ca> Date: Mon Jul 27 14:05:29 2015 -0700 Fix for http://sourceforge.net/p/tei/bugs/724/. I'm doing a string-replace which catches the specific bug reported (double quotes) in the title and author fields, but doesn't make any attempt to do more comprehensive escaping, since that would need a significant rewrite of large blocks of the code, I think. M VERSION M roma/romadom.php --------------- git log can also be massaged to output stuff in XML, by defining an XML format. So I'd like to suggest the following, to be piloted and tested with Roma, but then implemented for P5 (and any other projects which happen to be using gnuify-changelog.pl in our setup: Replace that call with an ant task which reads the existing XML log file (if it exists), calls git log to output anything subsequent to the last entry in XML, calls Saxon to XSLT it to whatever we want and insert it into the existing XML log file, then calls Saxon again to XSLT the now-updated XML log file into the GNU-preferred text format. Alternatively, if those of you who love PERL would like to simply update gnuify-changelog.pl so that it can use the git log output format, you're welcome to do that; it's a bit urgent because I don't think a build will work properly otherwise. Another option is to rely (for P5 builds) on having an svn checkout which can generate an svn log in the expected format, and using that; and then re-inserting gnuify-changelog.pl into the Roma tree, changing the Makefile to point to it, and doing other updates (adding and removing potential contributors) to both PERL files. I think the ant/XSLT solution is better in the long term, and removes one more PERL dependency, but I suspect I'm in a minority there. Cheers, Martin

Am 30.08.2015 um 19:23 schrieb Martin Holmes <mholmes@UVIC.CA>:
I think the ant/XSLT solution is better in the long term, and removes one more PERL dependency, but I suspect I'm in a minority there. I don’t think you are! Although ANT is far from being perfect (and already old-fashioned compared to grunt et al.) it’d help in getting OS independent for our build process(es). In the long term we should also strive for documenting the build process within the build scripts more thoroughly. I don’t know if ANT can help here (better than Make), though. But maybe this is an issue on its own to be debated on?
Best Peter

On 15-08-30 11:15 AM, Peter Stadler wrote:
Am 30.08.2015 um 19:23 schrieb Martin Holmes <mholmes@UVIC.CA>:
I think the ant/XSLT solution is better in the long term, and removes one more PERL dependency, but I suspect I'm in a minority there. I don’t think you are! Although ANT is far from being perfect (and already old-fashioned compared to grunt et al.)
The more I use ant, the more I like it, but I'm open to learning about better alternatives. I don't know grunt very well, but I always assumed it was intended mainly for JS rather than Java, and it depends on Node.js, which is another dependency. I think we'd start the conversation by listing out what we must have; and for me that's Java and Saxon. Using Saxon for large-scale transforms in an efficient manner then requires (as far as I can see) a Java-based build tool, and I think ant is the best candidate for that. After that we try to add only what's absolutely necessary, preferably stuff that doesn't require installation. The biggest problem is LaTeX, I suspect. If we could move to XSL:FO/FOP for PDF generation, a lot of requirements would go away.
it’d help in getting OS independent for our build process(es). In the long term we should also strive for documenting the build process within the build scripts more thoroughly.
Agreed. We could be much more verbose and less cryptic in the output messages, as well as the comments in the build files. I do like to see "Oh dear me. ERROR found" in the Makefile, but it's not as helpful as it could be.
I don’t know if ANT can help here (better than Make), though. But maybe this is an issue on its own to be debated on?
I think so. Cheers, Martin
Best Peter
participants (2)
-
Martin Holmes
-
Peter Stadler