Re: [boost] Issues with intel's compiler and newer builds of GCC

Subject: Re: [boost] Issues with intel's compiler and newer builds of GCC
From: Belcourt, K. Noel (kbelco_at_[hidden])
Date: 2010-10-20 17:53:07

On Oct 20, 2010, at 10:41 AM, Hartmut Kaiser wrote:

>>> 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?
>
> Not that I know of :-(
> We're trying to bring down Spirit's compilations times, but that's a  
> slow
> process...
>
> Couldn't we customize the max time before cutoff for compilers known  
> to be
> slow (icc) only?

Well it's not just Intel.  PGI is another very slow EDG based compiler.

Frankly I think five minutes is a pretty long time for a compiler to  
chew on a single source file.  Note that most of the Sandia hardware  
these tests run on is pretty high end server stuff (e.g. 8 core Intel  
5570's, 32 Gb memory and 500Gb local disks).  I point this out because  
most users have significantly less capable systems so they will  
experience significantly longer compile times.

Off the top of my head, I don't know how to alter Boost.Build to  
introduce a toolset dependent timeout though I'm sure it can be done.   
I'm just not at all convinced that we should do it.

-- Noel