[Top][All Lists]
[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
- bindir.at takes forever.,
Peter Rosin <=