Hallo Ralf,
On Jun 6, 2010, at 6:38 PM, Ralf Wildenhues <ralf.wildenh...@gmx.de>
wrote:
* Gary V. Vaughan wrote on Fri, Jun 04, 2010 at 07:50:31PM CEST:
Provide an m4sh reimplementation of announce-gen.
* libltdl/config/getopt.m4sh (M4SH_GETOPTS): New macro that takes
a quoted m4 list of command line options to be parsed, and
generates the shell code to parse those options and collect the
results into appropriately named 'opt_xxx' shell variables. Also,
add some private supporting macros, and improve the comments
radically.
* libltdl/config/announce-gen.m4sh: New file, to generate and
optionally post (an enhancement over the gnulib perl script of the
same name) a release announcement.
* Makefile.maint (announce-gen): Build a new announce-gen script
in the build directory, from the contents of
libltdl/config/announce-gen.m4sh.
* HACKING (Release Procedure): Update the instructions to use
announce-gen.
(Alpha release note template, Full release note template):
Removed.
I see the point in the factorization of the option parsing, and I have
to admit to not having tested or even looked in detail at these
changes
yet, but on a general note, shouldn't we either just use gnulib's
announce-gen if it is good enough for us? And if it isn't,
shouldn't we
try to get the improvements of your version into gnulib's, or even try
to get gnulib to adopt the libtool variant?
In general, I agree. But personally, I despise perl, and even had I
invested the effort in figuring out the correct string of punctuation
to make gnulib's version of announce-gen work for our release
process... I probably wouldn't have been able to read that code a week
later.
Anyway, perl rants aside, I think that alongside Autoconf's m4sh.m4sh
might make a better home for getopt.m4sh?
I'm not against the idea of replacing perl code in gnulib with m4sh
code either, though I think it might be a hard sell considering that
our announce-gen requires a bootstrap time "compilation" step to turn
announce-gen.m4sh into announce-gen the runnable shell script.
I realize my reaction to an earlier suggestion of yours about this
was a
bit inconsistent with this statement now, sorry about that. A bit
more
general, how come things like clcommit, mailnotify, and announge-gen
live in the Libtool package? They are not very specific to library
handling.
Well, we don't ship any of them, they are in git to help me with
commiting and releasing. Clcommit.m4sh and mailnotify.sh originally
came from cvs-utils, but have since diverged after we moved to git,
and ut seems cvs-utils is now unmaintained (and not terribly useful in
GNU projects nowadays anyway).
What do you think? And yes, I don't mind leaving things as they are,
this is just an observation. I realize you've just invested quite a
bit
of work on this.
Only announce-gen.m4sh is brand new, getopt.m4sh has been on my hard
drive in one for or another for quite a few years already.
Anyway, I'm not attached to holding on to any of these files in
libtool.git if there are better homes for them elsewhere. So, what
next? Should I propose getopt.m4sh to autoconf-patc...@gnu.org? And if
accepted, propose adoption of our getopt.m4sh using maintainer scripts
into gnulib?
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
