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

[Gary V. Vaughan]

Hallo Ralf,

Exorcising some ancient unmerged patches and related posts...

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 :-)


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

> 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

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

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

>   How can I find this out, and could something
> be done about it?

http://tkd.kicks-ass.net/GnuM4Project/BugReports is the first step.   
I'm not
really spending any time on M4 at the moment, while I try to help finish
Libtool 2.0.  After that, I'd be happy to look at it if you remind me.

>   Note I have shyed away from m4 as much as I could
> until now, so a documentation hint should suffice for a start.

I don't think the docs will help much here.  The code for M4 is  
(mostly) very
clean and easy to follow, and all the significant files have long  
comments at
the top that explain what they each do.

HTH,
    Gary.
--
Gary V. Vaughan      ())_.  gary@ 
{lilith.warpmail.net,gnu.org},address@hidden
Research Scientist   ( '/   http://www.tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/{libtool,m4}
Technical Author   `(_~)_   http://sources.redhat.com/autobook

PGP.sig
Description: This is a digitally signed message part