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 (gary@xxxxxxx) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
