[FYI] {master} tests: fix portability issues in 'repeated-options.test'
I've applied the attached patch to a temporary bugfixing branch, merged into master, and pushed. Regards, Stefano From 63796a15ef7d6cbff0fe734f8c293368183d6516 Mon Sep 17 00:00:00 2001 Message-Id: <63796a15ef7d6cbff0fe734f8c293368183d6516.1305463458.git.stefano.lattar...@gmail.com> From: Stefano Lattarini Date: Sun, 15 May 2011 14:41:35 +0200 Subject: [PATCH] tests: fix portability issues in 'repeated-options.test' * tests/repeated-options.test: Do not assume that object files have `.o' suffix and executables have no default suffix; instead, use `$(OBJEXT)' and `$(EXEEXT)'. --- ChangeLog |7 +++ tests/repeated-options.test | 12 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index c29d820..6b12300 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2011-05-15 Stefano Lattarini + + tests: fix portability issues in 'repeated-options.test' + * tests/repeated-options.test: Do not assume that object files + have `.o' suffix and executables have no default suffix; instead, + use `$(OBJEXT)' and `$(EXEEXT)'. + 2010-11-19 Stefano Lattarini New test on repeated automake options. diff --git a/tests/repeated-options.test b/tests/repeated-options.test index 84901f8..2f946b5 100755 --- a/tests/repeated-options.test +++ b/tests/repeated-options.test @@ -36,14 +36,20 @@ AUTOMAKE_OPTIONS = parallel-tests subdir-objects subdir-objects AUTOMAKE_OPTIONS += dist-bzip2 parallel-tests TESTS = foo.test EXTRA_DIST = $(TESTS) +TESTS_ENVIRONMENT = EXEEXT='$(EXEEXT)' bin_PROGRAMS = sub/foo +.PHONY: test-build +test-build: + ls -l . sub + test -f sub/foo.$(OBJEXT) + test -f sub/foo$(EXEEXT) END mkdir sub cat > foo.test <<'END' #!/bin/sh -test -f sub/foo && test -x sub/foo +test -f sub/foo$EXEEXT && test -x sub/foo$EXEEXT END chmod a+x foo.test @@ -64,9 +70,7 @@ $AUTOCONF ./configure $MAKE -ls -l . sub -test -f sub/foo.o -test -f sub/foo +$MAKE test-build $MAKE check ls -l test -f foo.log -- 1.7.2.3
[FYI] {maint} testsuite: be more cross-compile friendly
I've applied the attached patch to 'maint', rather than to 'testsuite-work',
only to make it easier to (potentially) backport tests for future bugfixing.
I plan to check in fixes tests that don't currently work in cross-compile
mode only in the 'testsuite-work' branch, to avoid excessive churn on
'maint' and 'master'.
Regards,
Stefano
From daa946a431442335bdf965e27b6f81f6c109fddc Mon Sep 17 00:00:00 2001
Message-Id:
From: Stefano Lattarini
Date: Sun, 15 May 2011 14:30:43 +0200
Subject: [PATCH] testsuite: be more cross-compile friendly
* tests/defs.in (cross_compiling): New subroutine.
(am__tool_prefix): New internal variable.
(gcc, g++, gcj): Force the use of the correct "tool prefix"
when cross compiling.
(gfortran, g77, non-cross): New requirements.
---
ChangeLog |9 +
tests/defs.in | 50 +++---
2 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b9c71f3..333e3ab 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2011-05-15 Stefano Lattarini
+
+ testsuite: be more cross-compile friendly
+ * tests/defs.in (cross_compiling): New subroutine.
+ (am__tool_prefix): New internal variable.
+ (gcc, g++, gcj): Force the use of the correct "tool prefix"
+ when cross compiling.
+ (gfortran, g77, non-cross): New requirements.
+
2011-05-07 Stefano Lattarini
tests: fix spurious failure of txinfo21.test on FreeBSD
diff --git a/tests/defs.in b/tests/defs.in
index 8f9534e..736a394 100644
--- a/tests/defs.in
+++ b/tests/defs.in
@@ -148,6 +148,23 @@ fail_ () { warn_ "$me: failed test: $@"; Exit 1; }
skip_ () { warn_ "$me: skipped test: $@"; Exit 77; }
framework_failure_ () { warn_ "$me: set-up failure: $@"; Exit 99; }
+# cross_compiling
+# ---
+# Tell whether we are cross-compiling. This is especially useful to skip
+# tests (or portions of them) that requires a native compiler.
+cross_compiling ()
+{
+ test x"$host_alias" != x
+}
+
+# So that we can force the use of correct gcc, g++ etc., consistently
+# with cross-compilation settings.
+if cross_compiling; then
+ am__tool_prefix="$host_alias-"
+else
+ am__tool_prefix=
+fi
+
for tool in : $required
do
# Check that each required tool is present.
@@ -195,24 +212,48 @@ do
# always use it. This is important only when the user
# has defined CC in his environment, otherwise ./configure will
# prefer gcc to other compilers.
- CC=gcc
+ CC=${am__tool_prefix}gcc
export CC
echo "$me: running $CC --version"
( $CC --version ) || exit 77
;;
gcj)
- GCJ=gcj
+ GCJ=${am__tool_prefix}gcj
export GCJ
echo "$me: running $GCJ --version"
( $GCJ --version ) || exit 77
( $GCJ -v ) || exit 77
;;
g++)
- CXX=g++
+ CXX=${am__tool_prefix}g++
export CXX
echo "$me: running $CXX --version"
( $CXX --version ) || exit 77
;;
+gfortran)
+ FC=${am__tool_prefix}gfortran
+ export FC
+ echo "$me: running $FC --version"
+ $FC --version || skip_ "GNU Fortran compiler not available"
+ echo "$me: running $FC -v"
+ $FC -v || skip_ "botched installation for GNU Fortran compiler"
+ case " $required " in
+*\ g77\ *) ;;
+*) F77=$FC; export F77;;
+ esac
+ ;;
+g77)
+ F77=${am__tool_prefix}g77
+ export F77
+ echo "$me: running $F77 --version"
+ $F77 --version || skip_ "GNU Fortran 77 compiler not available"
+ echo "$me: running $F77 -v"
+ $F77 -v || skip_ "botched installation for GNU Fortran 77 compiler"
+ case " $required " in
+*\ gfortran\ *) ;;
+*) FC=$F77; export FC;;
+ esac
+ ;;
icc)
CC=icc
export CC
@@ -251,6 +292,9 @@ do
rm -f $priv_check_temp
test $overwrite_status = 0 && exit 77
;;
+non-cross)
+ cross_compiling && skip_ "doesn't work in cross-compile mode"
+ ;;
python)
# Python doesn't support --version, it has -V
echo "$me: running python -V"
--
1.7.2.3
Re: [FYI] {parallel-tests-maint} docs: parallel-tests is not experimental anymore
Hi Stefano, * Stefano Lattarini wrote on Wed, May 11, 2011 at 04:07:46PM CEST: > The parallel-tests driver has now been used quite extensively > by a fair number of real-world applications (e.g., GNU coreutils, > GNU libtool, GNU grep, and various packages using Gnulib), and > thus exposed to adequate on-field testing. So there's no point > in declaring it experimental anymore (which would risk to make > potential users shy away from it). Well, the point of declaring it experimental is being able to do at least slightly incompatible changes and mostly getting away with it. The changes might not just be needed for portability reasons in the *current* code, but also for newer features in changed code. I'm willing to bet that your SoC project will turn up one or two such situations. Cheers, Ralf > * doc/automake.texi (Simple Tests using parallel-tests): Do not > declare the parallel-tests driver as "experimental" anymore.
Re: [FYI] {parallel-tests-maint} docs: parallel-tests is not experimental anymore
On Sunday 15 May 2011, Ralf Wildenhues wrote: > Hi Stefano, > > * Stefano Lattarini wrote on Wed, May 11, 2011 at 04:07:46PM CEST: > > The parallel-tests driver has now been used quite extensively > > by a fair number of real-world applications (e.g., GNU coreutils, > > GNU libtool, GNU grep, and various packages using Gnulib), and > > thus exposed to adequate on-field testing. So there's no point > > in declaring it experimental anymore (which would risk to make > > potential users shy away from it). > > Well, the point of declaring it experimental is being able to do at > least slightly incompatible changes and mostly getting away with it. > > The changes might not just be needed for portability reasons in the > *current* code, but also for newer features in changed code. I'm > willing to bet that your SoC project will turn up one or two such > situations. > > Cheers, > Ralf > > > * doc/automake.texi (Simple Tests using parallel-tests): Do not > > declare the parallel-tests driver as "experimental" anymore. > Should I revert this patch then? Or should we add a more "watered-down" warning in place of the previous "scary" one? Regards, Stefano
Re: [FYI] {parallel-tests-maint} docs: parallel-tests is not experimental anymore
* Stefano Lattarini wrote on Sun, May 15, 2011 at 04:10:29PM CEST: > On Sunday 15 May 2011, Ralf Wildenhues wrote: > > Well, the point of declaring it experimental is being able to do at > > least slightly incompatible changes and mostly getting away with it. > > > > The changes might not just be needed for portability reasons in the > > *current* code, but also for newer features in changed code. I'm > > willing to bet that your SoC project will turn up one or two such > > situations. > Should I revert this patch then? Or should we add a more > "watered-down" warning in place of the previous "scary" one? What was scary about the previous one? I didn't find it scary. Thanks, Ralf
Re: [FYI] {maint} testsuite: be more cross-compile friendly
* Stefano Lattarini wrote on Sun, May 15, 2011 at 03:48:43PM CEST:
> I've applied the attached patch to 'maint', rather than to 'testsuite-work',
> only to make it easier to (potentially) backport tests for future bugfixing.
> I plan to check in fixes tests that don't currently work in cross-compile
> mode only in the 'testsuite-work' branch, to avoid excessive churn on
> 'maint' and 'master'.
> Subject: [PATCH] testsuite: be more cross-compile friendly
>
> * tests/defs.in (cross_compiling): New subroutine.
> (am__tool_prefix): New internal variable.
> (gcc, g++, gcj): Force the use of the correct "tool prefix"
> when cross compiling.
> (gfortran, g77, non-cross): New requirements.
> --- a/tests/defs.in
> +++ b/tests/defs.in
> @@ -148,6 +148,23 @@ fail_ () { warn_ "$me: failed test: $@"; Exit 1; }
> skip_ () { warn_ "$me: skipped test: $@"; Exit 77; }
> framework_failure_ () { warn_ "$me: set-up failure: $@"; Exit 99; }
>
> +# cross_compiling
> +# ---
> +# Tell whether we are cross-compiling. This is especially useful to skip
> +# tests (or portions of them) that requires a native compiler.
> +cross_compiling ()
> +{
> + test x"$host_alias" != x
> +}
FWIW, this condition isn't the same as the one configure uses in order
to determine whether cross compilation is enabled or not. Is that an
oversight or on purpose? In the latter case, it would be prudent to
mention this in the comment.
Thanks,
Ralf
Re: [FYI] {parallel-tests-maint} docs: parallel-tests is not experimental anymore
On Sunday 15 May 2011, Ralf Wildenhues wrote: > * Stefano Lattarini wrote on Sun, May 15, 2011 at 04:10:29PM CEST: > > On Sunday 15 May 2011, Ralf Wildenhues wrote: > > > Well, the point of declaring it experimental is being able to do at > > > least slightly incompatible changes and mostly getting away with it. > > > > > > The changes might not just be needed for portability reasons in the > > > *current* code, but also for newer features in changed code. I'm > > > willing to bet that your SoC project will turn up one or two such > > > situations. > > > Should I revert this patch then? Or should we add a more > > "watered-down" warning in place of the previous "scary" one? > > What was scary about the previous one? I didn't find it scary. > I personally find the words "still experimental" quite scary :-) And potential users who agree with me on this might end up being scared away from the 'parallel-testsuite' feature, despite its great advantages and indisputable superiority -- which would be pretty sad IMHO. But than again, I might be the only "coward" here that is scared so easily :-) So your call in the end. Regards, Stefano
Re: [FYI] {maint} testsuite: be more cross-compile friendly
On Sunday 15 May 2011, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Sun, May 15, 2011 at 03:48:43PM CEST:
> > I've applied the attached patch to 'maint', rather than to 'testsuite-work',
> > only to make it easier to (potentially) backport tests for future bugfixing.
> > I plan to check in fixes tests that don't currently work in cross-compile
> > mode only in the 'testsuite-work' branch, to avoid excessive churn on
> > 'maint' and 'master'.
>
> > Subject: [PATCH] testsuite: be more cross-compile friendly
> >
> > * tests/defs.in (cross_compiling): New subroutine.
> > (am__tool_prefix): New internal variable.
> > (gcc, g++, gcj): Force the use of the correct "tool prefix"
> > when cross compiling.
> > (gfortran, g77, non-cross): New requirements.
>
> > --- a/tests/defs.in
> > +++ b/tests/defs.in
> > @@ -148,6 +148,23 @@ fail_ () { warn_ "$me: failed test: $@"; Exit 1; }
> > skip_ () { warn_ "$me: skipped test: $@"; Exit 77; }
> > framework_failure_ () { warn_ "$me: set-up failure: $@"; Exit 99; }
> >
> > +# cross_compiling
> > +# ---
> > +# Tell whether we are cross-compiling. This is especially useful to skip
> > +# tests (or portions of them) that requires a native compiler.
> > +cross_compiling ()
> > +{
> > + test x"$host_alias" != x
> > +}
>
> FWIW, this condition isn't the same as the one configure uses in order
> to determine whether cross compilation is enabled or not. Is that an
> oversight or on purpose?
>
Oversight, sorry (it's basically the first time I'm doing cross-compilation,
if that's any excuse). What condition should I use instead?
I will do the fix in a follow-up patch.
> In the latter case, it would be prudent to mention this in the comment.
>
> Thanks,
> Ralf
>
Thanks, and sorry for the noise,
Stefano
Re: [FYI] {maint} testsuite: be more cross-compile friendly
On Sunday 15 May 2011, Stefano Lattarini wrote:
> On Sunday 15 May 2011, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Sun, May 15, 2011 at 03:48:43PM CEST:
> > > I've applied the attached patch to 'maint', rather than to
> > > 'testsuite-work',
> > > only to make it easier to (potentially) backport tests for future
> > > bugfixing.
> > > I plan to check in fixes tests that don't currently work in cross-compile
> > > mode only in the 'testsuite-work' branch, to avoid excessive churn on
> > > 'maint' and 'master'.
> >
> > > Subject: [PATCH] testsuite: be more cross-compile friendly
> > >
> > > * tests/defs.in (cross_compiling): New subroutine.
> > > (am__tool_prefix): New internal variable.
> > > (gcc, g++, gcj): Force the use of the correct "tool prefix"
> > > when cross compiling.
> > > (gfortran, g77, non-cross): New requirements.
> >
> > > --- a/tests/defs.in
> > > +++ b/tests/defs.in
> > > @@ -148,6 +148,23 @@ fail_ () { warn_ "$me: failed test: $@"; Exit 1; }
> > > skip_ () { warn_ "$me: skipped test: $@"; Exit 77; }
> > > framework_failure_ () { warn_ "$me: set-up failure: $@"; Exit 99; }
> > >
> > > +# cross_compiling
> > > +# ---
> > > +# Tell whether we are cross-compiling. This is especially useful to skip
> > > +# tests (or portions of them) that requires a native compiler.
> > > +cross_compiling ()
> > > +{
> > > + test x"$host_alias" != x
> > > +}
> >
> > FWIW, this condition isn't the same as the one configure uses in order
> > to determine whether cross compilation is enabled or not. Is that an
> > oversight or on purpose?
> >
> Oversight, sorry (it's basically the first time I'm doing cross-compilation,
> if that's any excuse). What condition should I use instead?
>
OK, we could use the `$cross_compiling' variable inside configure.ac, but
obviously not inside `tests/defs'.
My idea is that a simple:
$ make check host_alias='...'
should suffice to run the testsuite in cross-compile mode -- and this is
what I'm succesfully doing right now.
But maybe it should be safer and more correct to follow the configure logic
more closely when determining whether cross-compilation is in effect; i.e.,
our definition of `cross_compiling' should become something like:
host_alias=${host_alias-'@host_alias@'}
build_alias=${build_alias-'@build_alias@'}
cross_compiling ()
{
test x"$host_alias" != x && test x"$build_alias" != x"$host_alias"
}
WDYT?
Regards,
Stefano
