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
>>> The logs from the build machine have warnings. These warnings are
>>> identical to ones that I get with MSVC-7.1 when building
>>> (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,
>>> 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
>>> 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.
>> 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
>> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk