autoconf
[Top][All Lists]
Advanced

[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: Eric Blake
Subject: Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582
Date: Mon, 07 Jun 2010 19:37:16 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre Mnenhy/0.8.2 Thunderbird/3.0.4

[adding autoconf]

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.

> 
> 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.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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