libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bindir.at takes forever.


From: Peter Rosin
Subject: bindir.at takes forever.
Date: Tue, 28 Sep 2010 14:28:48 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Hi!

I have been looking at the loops in tests/bindir.at and I see
this:

  for bindir in \
        $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin/ \
        $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin \
        $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0/ \
        $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
        $curdir/usr/lib/gcc/i686-pc-cygwin/bin/ \
        $curdir/usr/lib/gcc/i686-pc-cygwin/bin \
        $curdir/usr/lib/gcc/i686-pc-cygwin/ \
        $curdir/usr/lib/gcc/i686-pc-cygwin \
        $curdir/usr/lib/bin/ \
        $curdir/usr/lib/bin \
        $curdir/usr/bin/ \
        $curdir/usr/bin \
        $curdir/bin/ \
        $curdir/bin \
        /tmp/foo/bar ;
  do

     ...

  done

Is it really necessary to check *all* components with the trailing slash?
And do we really need to test so many levels? Looks like the tests time
could be cut dramatically with little risk of causing a regression.

That would be very useful to me, since I have this for MSYS/MSVC:
54. bindir install tests (bindir.at:190): ok     (20m5.264s 16m18.552s)
and this for Cygwin/MSVC:
54. bindir install tests (bindir.at:190): ok     (18m47.361s 24m34.475s)

I know the test is designed to mimic what GCC is doing when it is built,
but this is a bit over the top if you ask me. And I can't imagine that
GCC is using all those variations of bindir...

Thoughts?

Cheers,
Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]