[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gary V. Vaughan
Subject: Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582
Date: Tue, 8 Jun 2010 15:02:25 +0700

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.

Gary V. Vaughan (address@hidden)        

reply via email to

[Prev in Thread] Current Thread [Next in Thread]