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? Regards Hartmut --------------- http://boost-spirit.com