Re: ensure $MV is set before each use [libtool--gary--1.0--patch-30]

[Ralf Wildenhues]

[ BTW, could you get your mailer to do decent quote wrapping?  Thanks ]

* Gary V. Vaughan wrote on Mon, Aug 29, 2005 at 01:28:21AM CEST:
> On 10 May 2005, at 09:53, Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Sat, May 07, 2005 at 04:30:46PM CEST:
> >>Okay to commit to HEAD and branch-2-0?
> >>
> >>    Some macros had relied on accidentally correct ordering in order
> >>    for $MV to be defined before use.  Factor out setting of some
> >>    common file commands and m4_require it before use:
> >>
> >>    * libltdl/m4/libtool.m4 (_LT_PROG_DEFAULTS): Allow user to
> >
> >There is not file libltdl/m4/libtool.m4 (but I may be dealing with  
> >your patches in the wrong order? :-)
> 
> There is now, and yes you were :-)

OK.

> >>    override some common file commands at configure time.
> >>    (_LT_SETUP, _LT_CONFIG, _LT_COMPILER_OPTION, _LT_LINKER_OPTION)
> >>    (_LT_COMPILER_C_O, _LT_COMPILER_FILE_LOCKS)
> >>    (_LT_SYS_DYNAMIC_LINKER, _LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
> >>    (_LT_SYS_HIDDEN_DEPLIBS): m4_require it to ensure the commands  
> >>    are defined before they are called.
> >
> >I don't see where MV or CP are used at `configure' time, only RM, but
> >that's ok.  Also, I believe I want to be able to choose a different RM
> >at configure time than at compile time, for debugging reasons.   
> >This too is possible with your patch.
> >
> >That brabbling done, I like your patch, please apply.  The only
> >change I request you to think about is maybe a different name -- how
> >about _LT_FILEUTILS_DEFAULTS?
> 
> Okay, name changed and about to commit (assuming distcheck still  
> passes).

OK.

> >Thinking out loud, it might be a good idea to merge my proposed
> >_LT_CHECK_POSIX_SORT (and similar tests which might prove necessary  
> >for some of the other tools) to a _LT_FILEUTILS_POSIX which tests all
> >of them.
> 
> Seems reasonable.  But unless it is addressing a bug... we have to wait
> until after 2.0 now :-D

OK, whatever.

> >BTW, we eventually need to talk about m4 execution time, too.
> >bootstrapping HEAD is much slower than branch-2-0, which in turn is  
> >much slower than branch-1-5.
> 
> I think this is mostly because they are each doing considerably more at
> bootstrap time.  When the tests/demo* dirs have been migrated to  
> autotest HEAD will be *much* (at least an order of magnitude) faster
> again.

I am NOT talking about the number of autoreconf invocations.  I am
talking about the time ONE autoreconf invocation takes.

> >Does m4 scale exponentially in the maximal encountered macro depth?
> 
> I don't believe so.  Though only a careful analysis of the code could  
> make certain.

Almost all the time is spent in building the list of tag decls, I
believe.  I know it's at least quadratic in the number of decls, but it
may also be even higher, haven't looked at it closely.  So maybe it's
not M4 but ltsugar.m4 and parts of libtool.m4 that would need a rewrite.

*snip*

Cheers,
Ralf