Boost logo

Boost :

Subject: Re: [boost] Issues with intel's compiler and newer builds of GCC
From: John Maddock (boost.regex_at_[hidden])
Date: 2010-10-20 12:11:55

>> > If the build bots aren't using v4.5 of GNU's standard library, then I'm
>> > at
>> > a loss
>> > as to why Serialization is failing to build on them. My only other
>> > thought
>> > is that
>> > the timeout for the build cycle is too low - the failures indicate that
>> > the error
>> > is a timeout after 300 seconds.
>> I see what you mean... not very helpful!
>> The best you can do is contact the test runner for more info.
> How do I do this?

Click on the test runner name, and you'll get to a page like this: that
hopefully has what you need to know.

> This is now a problem for the MSVC-7.1 test, too. It, too, times out. The
> logs from
> the build machine have warnings. These warnings are identical to ones that
> I get
> with MSVC-7.1 when building Serialization (rather, the warnings shown on
> the build
> logs are a subset of the warnings I get, the logs seem to cut off after a
> certain
> amount of warnings, e.g. 65k). Building Serialization with MSVC-7.1 passes
> all
> tests on my machine and builds all examples, without any trouble.
> I'm sure the argument could be made that five minutes (300 seconds) is
> more than
> reasonable, and the XML grammar for Serialization could definately be
> refactored
> (it's structure is nearly identical to the old Spirit.Classic grammar; I
> didn't
> want to get fancy). However, the grammar works, and I'd really like to not
> have
> false negatives from the build machines. This is, to my knowledge, the
> first
> component of Boost that uses Spirit 2.x (Hartmut/Joel please correct me if
> I am
> wrong. Wave uses Spirit Classic, I believe). The Spirit 2.x examples
> aren't
> compiled by the tests, so I am assuming that this is the first time the
> build bots
> have compiled larger Spirit 2.x parsers.
> The compile times for MSVC 10, GCC and clang are all far more reasonable
> than
> Intel and MSVC 7.1 on my machines.

I agree that the time limit can be pretty annoying - I had to refactor a
large number of the Boost.Math tests to avoid long run times. However, the
limit is not unreasonable either - it is important that the tests cycle in a
reasonable time - remember that the CPU time on the build bots has all been
graciously donated, and isn't entirely free of cost. We also need to
consider the impact on the end user of long compile times, also on the
occasional "casual" tester of Boost.Serialization - the time taken to run
all the tests is pretty long, so anything that can be done to reduce that
would be a big win.

Would it be worth getting the spirit2 developers in on this to see if there
is any low-hanging fruit that can be pulled?

Cheers, John.

PS lots of Linux testers are failing with unresolved externals: as well, sorry :-(

Boost list run by bdawes at, gregod at, cpdaniel at, john at