On 02/09/2012 12:05 PM, Peter Rosin wrote:
> Stefano Lattarini skrev 2012-02-09 11:36:
>> Sorry to answer to myself, but I think I've found a better, simpler
>> and more appropriate way to speed up the depcomp+libtool tests.  See
>> attached patch.
>>
>> OK for master?
> 
> I was wondering about the multiple libtool runs, but figured there
> was some difference if you only built shared or only built static,
> compared to doing both in the same build.  But that does not seem to
> be the case if I read the rationale for this change.
>
Well, duh!  By re-reading the diffs of commit e89ec38d (which is my only
reference in this matter), it seems that your objection is correct and my
rationale is wrong, in that the bug fixed by that commit presented itself
only when the building of shared libraries was somehow disabled.  So we
still need to go with something similar to the first patch -- but, unless
I'm again mistaken, we need do the extra checks only for the depmodes for
which the location of the compiler-generated depfiles can depend on which
flavour of libraries are being built by libtool.  Attached is a patch that
attempts to do so.  Since my brain clearly isn't functioning properly in
this matter, I will wait for an ACK before pushing.

Thanks,
  Stefano

>From ab75665a57d334d0f3a11390cf4f25f2d8f1a33e Mon Sep 17 00:00:00 2001
Message-Id: <ab75665a57d334d0f3a11390cf4f25f2d8f1a33e.1328792918.git.stefano.lattar...@gmail.com>
From: Stefano Lattarini <stefano.lattar...@gmail.com>
Date: Wed, 8 Feb 2012 13:21:58 +0100
Subject: [PATCH] depcomp tests: avoid redundant runs for libtool tests

When running libtool-oriented tests, our 'depcomp.sh' script used
to run the same checks thrice: once after having run configure
with the '--disable-shared' option, once after having run it with
the '--enable-shared' option, and once by allowing configure to
automatically select which kind of library (or libraries) to build.

This was done to offer extra coverage for the less-common depmodes
(like "aix" of "hp2") where the name of the compiler-generated
depfiles can depend on whether libtool is in use *and* on which
kind of libraries libtool is building (static, shared, or both).
About this, see commit 'Release-1-10-24-ge89ec38' of 28-03-2007,
"* lib/depcomp (aix): Rewrite depmode in the spirit of the tru64
one".

But that extra coverage came at the price of *considerably* slowing
down the depcomp libtool-oriented tests, since for each of them the
tested source tree was configured and built *twelve* times (rather
than "just" four as it is for the non-libtool case).

So, to strike a balance between coverage and speed, we now run the
libtool-oriented tests with the three different configuration modes
*only* when it is possible that the depmode that will get selected
is one of those which can actually benefit from the extra coverage.

* tests/depcomp.sh: Adjust to only run the threefold libtool tests
when that can truly be potentially useful.  Add related explanatory
comments.
---
 tests/depcomp.sh |   38 +++++++++++++++++++++++++++++---------
 1 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/tests/depcomp.sh b/tests/depcomp.sh
index 67db770..a53c0b5 100755
--- a/tests/depcomp.sh
+++ b/tests/depcomp.sh
@@ -148,7 +148,6 @@ mkdir build-aux sub src src/sub2
 
 case $depcomp_with_libtool in
   yes)
-    plan_ 84
     po=Plo objext=lo a=la
     normalized_target=libfoo_la
     LIBPRIMARY=LTLIBRARIES LINKADD=LIBADD
@@ -166,7 +165,6 @@ case $depcomp_with_libtool in
     }
     ;;
   no)
-    plan_ 28
     po=Po objext='$(OBJEXT)' a=a
     normalized_target=foo
     LIBPRIMARY=LIBRARIES LINKADD=LDADD
@@ -260,14 +258,42 @@ $ACLOCAL && $AUTOCONF && $AUTOMAKE -a \
 test -f build-aux/depcomp \
   || fatal_ "depcomp script not installed"
 
+# To offer extra coverage for the depmodes (like "aix" of "hp2") where the
+# name of the compiler-generated depfiles can depend on whether libtool is
+# in use *and* on which kind of libraries libtool is building (static,
+# shared, or both), we would like to run the libtool-oriented tests thrice:
+# once after having run configure with the '--disable-shared' option, once
+# after having run it with the '--enable-shared' options, and once by
+# leaving it to configure to automatically select which kind of library (or
+# libraries) to build.
+#
+# But doing such three-fold checks unconditionally for all the depmodes
+# would slow down the already too slow libtool tests unacceptably (up to a
+# 150-200% factor), with no real gain in coverage for most of the depmodes.
+# So, since the depmodes that would benefit from the extra tests are never
+# forced to configure in out tests below, but can only be automatically
+# selected by '--enable-dependency-tracking', we make this threefold check
+# only in this later case.
+
 case $depmode in
   auto)
+    plan_ 84
+    do_all_tests ()
+    {
+      do_test default
+      do_test noshared --disable-shared
+      do_test nostatic --disable-static
+    }
     displayed_depmode='..*' # At least one character long.
     cfg_deptrack=--enable-dependency-tracking ;;
   disabled)
+    plan_ 28
+    do_all_tests() { do_test; }
     displayed_depmode=none
     cfg_deptrack=--disable-dependency-tracking ;;
   *)
+    plan_ 28
+    do_all_tests() { do_test; }
     displayed_depmode="(cached) $depmode"
     cfg_deptrack="$cachevar=$depmode"
     # Sanity check: ensure the cache variable we force is truly
@@ -378,13 +404,7 @@ do_test ()
 }
 
 for vpath in no simple long absolute; do
-  if test $depcomp_with_libtool = no; then
-    do_test
-  else
-    do_test default
-    do_test noshared --disable-shared
-    do_test nostatic --disable-static
-  fi
+  do_all_tests
 done
 
 :
-- 
1.7.7.3

Reply via email to