incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: Building Tests
Date Mon, 24 Mar 2008 23:24:04 GMT
 

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Friday, March 21, 2008 5:41 PM
> To: dev@stdcxx.apache.org
> Subject: Re: Building Tests
> 
> Eric Lemings wrote:
> >  
> > I haven't looked to confirm this but it looks like the Makefile(s)
> > ignore errors building the test programs but the build process still
> > stops (i.e. exits successfully).  I was wondering if the Makefile(s)
> > shouldn't also continue building the remaining test 
> programs (i.e. set
> > MAKEFLAGS=-k before invoking the test Makefile).
> 
> I don't think the makefiles ignore build errors.

If you do a build on a platform where one of the test programs fails
to build, the make process will exit and will not build the remaining
test programs but the run target will still try to run these unbuilt
tests.

Example:

	$ cd $BUILDDIR/tests && gmake
	...
	aCC -c  -D_RWSTDDEBUG   -mt
-I/amd/devco/lemings/work/stdcxx/trunk.blokus/include
-I/build/lemings/stdcxx/include
-I/amd/devco/lemings/work/stdcxx/trunk.blokus/tests/include  -AA  -g +d
+w +W392 +W655 +W684 +W818 +W819 +W849
/amd/devco/lemings/work/stdcxx/trunk.blokus/tests/tr1.util/2.smartptr.sh
ared.cpp
	Error 440:
"/amd/devco/lemings/work/stdcxx/trunk.blokus/include/tr1/_smartptr.h",
line 216 # Cannot initialize 'volatile Base_0<int> *' with 'volatile
Derived<int> *const'.
	            : _C_pbody (__rhs._C_pbody), _C_ptr (__rhs._C_ptr) {
	                                                 ^^^^^^^^^^^^
	Error 445:
"/amd/devco/lemings/work/stdcxx/trunk.blokus/tests/tr1.util/2.smartptr.s
hared.cpp", line 270 # Cannot recover from earlier errors.
	    static void
	    ^^^^^^^^^^^
	gmake: *** [2.smartptr.shared.o] Error 2

> The only processes
> that continue after errors is configuration and the run target. And
> of course, in nightly builds we ignore all but library build errors
> by explicitly invoking make with -k as you said.

Right, and since the run target continues but the test build does not,
the run output will look something like this when one of the test
programs failed to build:

	$ gmake run
	...
	18.limits.stdcxx-436                       NOUT    0
0.010   0.010   0.040
	18.limits.traps                               0    0      16
0   100%   0.010   0.010   0.030
	18.numeric.special.float                      0    0     119
6    94%   0.010   0.010   0.020
	18.numeric.special.int                        0    0     434
13    97%   0.000   0.010   0.020
	18.setjmp                                     0    0       3
0   100%   0.010   0.010   0.030
	19.cerrno                                     0    0       5
0   100%   0.010   0.010   0.030
	19.exceptions.mt                              0    0       0
0   100% 131.440  14.460  64.990
	2.smartptr.shared                          COMP    0
0.000   0.000   0.000
	2.smartptr.weak                            COMP    0
0.000   0.000   0.000
	20.auto.ptr                                COMP    0
0.000   0.000   0.000
	20.function.objects                        COMP    0
0.000   0.000   0.000
	20.operators                               COMP    0
0.000   0.000   0.000
	20.pairs                                   COMP    0
0.000   0.000   0.000
	...

All the remaining tests fail with "COMP" status.

So, I think it makes sense that if the run target tries to run all
tests, then the target that builds the test programs should also
try to build as many test programs as possible.  Either that or
make the target that runs each test output dependent on the
respective test program so it only tries to run it if it is up to
date.

Brad.

Mime
View raw message