Re: subdir-object compatibility Autotests [libtool--devo--1.0--patch-260]

[Gary V. Vaughan]

Bob Friesenhahn wrote:
> On Wed, 13 Oct 2004, Noah Misch wrote:
>
> > This framework uses the user's installations of Autoconf and Automake to
> > bootstrap the tests, so the test suite will actually test libtool's 
> > behavior on
> > platform-acversion-amversion tuples.  Is that intentional?  I kind of 
> > like that,
> > since the suite will test the collection of tools the user will 
> > actually employ.
> >
> > If the test suite comes to run all tests in this manner, it will 
> > probably take
> > about twice as long to run.  I suppose that is worth the added precision.

At the moment, it does about 4x as much work as the legacy framework at
test time, but has about 1/8th of the work it used to do when committing 
and updating from CVS... When we have migrated more of the tests I can
cut that back quite a bit, limited to somewhere around half of that.  At
the moment each test in the single test group is doing a full 
autoreconf.  We can organise the groups into tests that run in the same 
 tree (much like the legacy tests, only with more flexibility) to 
achieve that.

> Except for under MinGW/Cygwin where it will likely take 10x as long. :-(

There are a number of things that can be done to mitigate that beyond 
what I've said above: After libtool-2.0, I'll likely refocus on 
finishing M4-2.0 for a few months.  M4-2.0 is already about 10-20% 
faster that 1.4.2 for autoconf related tasks, and can be improved at 
least another 20%, and maybe as much as 50% by replacing some of the
guts of m4sugar.m4 with C modules.

Also, we can move more of ltmain.m4sh to m4 time to reduce the load on 
the shell.

Finally, considering that the bottleneck for Windows is it's pitiful 
fork() characteristics, I wonder why no-one has bundled a shell with
the common commands builtin, and back-ticks implemented as a recursive
call rather than a fork?  Imagine how much faster mingw shell scripts
would run if the echo "foo" | sed bar stanza all ran in the current
process! :-)

> The good news is that Autoconf and Automake do install properly under 
> MinGW/Cygwin.  Sooner or later we will encounter a target where this is 
> not feasable or the effort is otherwise prohibitive.  Should we worry 
> about that?

I'm not sure what you mean.  Please explain.

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

signature.asc
Description: OpenPGP digital signature