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

[Gary V. Vaughan]

Hallo Ralf, Eric,

On 6 Jun 2010, at 19:46, Ralf Wildenhues wrote:
> * 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?

Sure.  When I rewrote announce-gen in a maintainable language ;-) it
was because I thought it unseemly to ask Jim to change some aspects
of his script for Libtool's use... and also because it was more
fun and less time consuming for me to spend an evening writing a few
hundred lines of shell code than dirtying my hands with perl, and
then trying to shepherd that code into Jim's script while I could
still understand it!

Still, if someone else wants to backport and translate the m4sh
differences back into gnulib's perl code, that seems like a net win
to me, and we should at least consider adopting that canonical
version back into Libtool.

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

That's true.  But all the func_* thingies are very low level, and
provide a nice layer to write shell scripts over, so I suppose they
too would be a useful addition to m4sh, and are entirely contained
in general.m4sh.  I'll admit that some refactoring is certainly
desirable if adoption of that code into autoconf turns out to be the
path we take.

It bears mentioning that my original vision for m4-2.0 was to implement
and ship much of m4sh there, with key parts rewritten as loadable modules
to improve performance over the pure m4 version... and that autoconf-3.0
would be able to build on.  In that case, getopt.m4sh and general.m4sh
more properly belong in m4-2.0's m4sh, although I don't think that
precludes a version of pure m4 getopt.m4sh/general.m4sh living inside
autoconf-2.xx in the mean time.

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

It's a pity that m4sh hasn't caught on.  I find it to be a very
pleasant and productive shell script development environment. I
don't know whether that's because the compilation phase is still
immature, or simply because it's buried so deep in the current
Autoconf/Libtool distributions that no one has noticed it?  It
would be nice if we could find some means to fix that though.

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

Good idea.  Thanks.

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

Agreed. :'(

Cheers,
-- 
Gary V. Vaughan (address@hidden)