[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.
Cheers,
--
Gary V. Vaughan (address@hidden)