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

[Ralf Wildenhues]

Hi Gary, Eric,

* Gary V. Vaughan wrote on Sun, Jun 06, 2010 at 02:13:35PM CEST:
> On Jun 6, 2010, at 6:38 PM, Ralf Wildenhues 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.

Yes, granted, but, err, I'm not sure how to phrase it, if Jim is
maintaining that code, and we can just use it, with possibly minor
changes, why shouldn't we do it and not worry much about the
implementation language?  (Disclaimer: I haven't tested either so
far.)  If you don't want to get into the business of doing this bit
of work, maybe somebody else can do that?

The next question is orthogonal to the announce-gen one:

> Anyway, perl rants aside, I think that alongside Autoconf's
> m4sh.m4sh might make a better home for getopt.m4sh?

I don't know, possibly yes, although the code uses quite a bit of
libtool-specific details (like all the referenced func_* thingies),
and I must admit having a pretty hard time grasping the m4.
(I'm much easier with perl, but hey, that might be something I should
just live with. ;-)

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

Yes, that sounds like a hard sell.

> Anyway, I'm not attached to holding on to any of these files in
> libtool.git if there are better homes for them elsewhere. So, what
> next? Should I propose getopt.m4sh to address@hidden

If it can be separated from libtool details, it sounds like a viable
approach.  Let me put Eric in Cc: to see if the Autoconf maintainer
opposes this idea, to avoid you possibly-unnecessary work.

> And
> if accepted, propose adoption of our getopt.m4sh using maintainer
> scripts into gnulib?

I bet that'll still be a hard sell even then.  ;-)

Cheers,
Ralf