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

[Gary V. Vaughan]

Hi Eric,

On 8 Jun 2010, at 08:37, Eric Blake wrote:
> On 06/06/2010 06:13 AM, Gary V. Vaughan wrote:
>>> 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?
> 
> Yes, I think (given the current contents of m4sh.m4 in autoconf) that
> the intent has been there for several years to add generic m4sh support
> for option parsing; but it is undocumented, and woefully undertested.
> I'm all for improving it - m4sh is indeed the right place to provide an
> option parsing library.  But it will have to wait until after autoconf
> 2.66 is released.

Thanks for the encouraging feedback.  I'll reraise the getopt issue after
2.66 has landed.

>> 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.
> 
> On the gnulib side of things, a pre-compiled runnable shell script can
> be checked in, along with a make rule to regenerate that script from the
> .m4sh sources.  Jim may be on the opposite side of the fence from you
> (he prefers perl over portable shell), but it would certainly be worth
> raising the issue on the gnulib list, once autoconf has better m4sh
> support for option parsing.  Or perhaps both scripts can live in gnulib,
> perl and m4sh versions, side-by-side.  The beauty of gnulib is that it
> provides a nice source for pieces you care about, even if you don't use
> every piece available.  So it does seem like a better (eventual) home
> for these recent libtool m4sh scripts.

And once we have a nicely generalized getopt.m4sh in Autoconf, I'll
reraise this issue on the gnulib lists.

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