* 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
