Re: [PATCH] Use getopt.m4sh to generate libtool option parser.

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Tue, Jun 22, 2010 at 07:42:27AM CEST:
> On 22 Jun 2010, at 00:59, Ralf Wildenhues wrote:
> > However, this makes me more cautious
> > about your other patch for using this machinery for the libtool script
> > itself: that is created in packages using Libtool,
> 
> Not true.  We distribute libtoolize.in and ltmain.sh, for both of which
> the bootstrap time m4sh expansions have already been made.  The only
> time users will notice any difference is if they want to bootstrap from
> the repository using a more than 4 year old Autoconf.

Ah, thinko of mine.  Thanks for explaining to me.

> > If it can be made 2.59-compatible (and the other issues noted in that
> > thread are fixed) then ok, otherwise I would suggest bumping required
> > Autoconf for libtool.m4 to 2.62 before the Libtool 2.2.14 release and
> > using the getopt machinery for ltmain then, so that with 2.2.12, users
> > still have a 2.62-buildable Libtool with cautious requirement on their
> > own packages.  Does that make sense?
> 
> Actually I was thinking of adding m4_version_prereq(2.61) to just
> getopt.m4sh, since that will at least give a useful diagnostic to libtool
> bootstrap users who want bleeding edge libtool and ancient autoconf to
> work together.

Good idea!

> As long as other users are content with the libtoolize.in and ltmain.sh
> that come with the libtool release tarballs (or are in the habit of
> updating their Autotools within a few years of each other before they
> bootstrap git clones), they won't notice anything.
> 
> WDYT?

Agreed.

> On 12 Jun 2010, at 17:45, Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Sat, Jun 12, 2010 at 12:34:04PM CEST:
> >> On 12 Jun 2010, at 15:48, Ralf Wildenhues wrote:

> >>> The handling of --dlopen=..., --mode=..., --tag=..., now increased by
> >>> two forks and one exec per such flag on systems with decent shells, and
> >>> it doesn't use safe $ECHO any more even on systems with indecent shells,
> >>> because you don't use func_opt_split any more.  My guess is that this
> >>> would increase libtool execution time for typical compile commands by
> >>> a noticeable amount, since we got them down to about half a dozen forks.
> >>> Please fix this.
> >> 
> >> That's quite an invasive change, since the core of the M4SH_GETOPTS
> >> generated code will then rely on the XSI functions you add to libtool at
> >> configure time.  I suppose we need to put them in, say,
> >> libltd/config/xsi.m4sh where libtoolize, commit, announce-gen,
> >> mailnotify and any future m4sh scripts can reap the benefits.  This
> >> in turn means we need to move it into a separate macro to contribute
> >> back to Autoconf when we move getopt.m4sh and supporting code.
> > 
> > I'm fine with not using XSI for all other scripts; the func_opt_split
> > could be trivial forwarders for the sed scripts there; that would avoid
> > having to beef up infrastructure here, IIUC.  But the libtool command
> > line parsing really was one of the time critical issues in user builds,
> > and --mode and --tag are pervasive, so this would be a real regression.
> 
> I'm still not clear on how to implement this cleanly.  I'd like to be
> able to figure it all out at bootstrap time:

That works portably only if you put the XSI-relevant tests in a
subshell, otherwise an old shell may spew errors and even die due to
syntax errors.  But a subshell regresses on time again.  Can't you
optionally allow to specify to the machinery "the functions X and Y
have already been specified for you externally"?

Cheers,
Ralf