Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582

[Gary V. Vaughan]

Hallo Ralf,

On Jun 6, 2010, at 6:38 PM, Ralf Wildenhues <address@hidden>  
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 address@hidden And if  
accepted, propose adoption of our getopt.m4sh using maintainer scripts  
into gnulib?

Cheers,
--
Gary V. Vaughan (address@hidden)