develooper Front page | perl.perl5.porters | Postings from May 2013

Re: Build failed in Jenkins: perl5 #2285

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
May 8, 2013 07:04
Subject:
Re: Build failed in Jenkins: perl5 #2285
Message ID:
20130508070401.GO3729@plum.flirble.org
On Tue, May 07, 2013 at 01:32:30PM +0200, Dennis Kaarsemaker wrote:
> On Tue, 2013-05-07 at 09:55 +0100, Nicholas Clark wrote:
> > 
> > As to why Jenkins is running g++ not gcc - not sure. There was probably a
> > discussion about it at some point, and it was assumed that threaded g++
> > would give the most "bang for your buck" in terms of one configuration to
> > find the most problems.
> > 
> It's doing both. A single test of perl does:
> 
> git clean
> git reset
> configure/build/test with gcc
> git clean
> git reset
> configure/build/test with g++
> 
> The perl5-threaded test is the same, except with a threaded perl.

I was wondering. If it's currently doing

    ./Configure ...
    make -j8 test_prep
    TEST_JOBS=8 make -j8 test_harness

whether changing that middle step to

    make -j8 test_prep || make test_prep

would give better log output.

If the parallel make passes, the serial make is skipped, so no slowdown.
But if the parallel make fails, then the serial make will (probably) also
fail, but it its last logged output will be the point of failure. Not the
7 other things that started at the same time as the problem, but took a while
to complete.


Also, I believe that on glibc the not-very documented environment variables
for malloc give some amount of error checking for little extra code. So it
might be worth running the tests with something like

    MALLOC_PERTURB_=N MALLOC_CHECK_=2

On Tue, May 07, 2013 at 06:11:21PM -0600, Karl Williamson wrote:
> On 05/07/2013 02:55 AM, Nicholas Clark wrote:
> > As to why Jenkins is running g++ not gcc - not sure. There was probably a
> > discussion about it at some point, and it was assumed that threaded g++
> > would give the most "bang for your buck" in terms of one configuration to
> > find the most problems.
> 
> Jenkins is running both, and it is running g++ at my request.  And the 
> reason was that these types of errors would get into blead and stay 
> until someone bothered to compile with g++ (usually me).  We do support 
> C++ headers, and the easiest way to do that is to compile the whole 
> thing in C++.  Besides, it is possible that the messages from C++ may 
> catch problematic constructs that wouldn't work as expected.

Yes, we need to test that the headers are clean for C++.
We didn't use to, and we certainly screwed it up once (The 5.8.8 release,
IIRC)

And yes, for various reasons, the easiest way to test this is to build the
core with a C++ compiler. But there's actually no need for the core to be
able to be *installed* if built with a C++ compiler.

> I remember when C++ came out; it was billed as a "better C" even if you 
> didn't want to use its OO capabilities.  Perhaps C compilers have 
> improved in the intervening decades; I don't know.


Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About