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: Robert Ramey (ramey_at_[hidden])
Date: 2010-10-20 15:50:57

Bryce Lelbach wrote:
> There's a lot of room in the grammar for refactoring; some of the
> productions in the grammar are now deprecated in the XML standard (in
> favor of less annoying rules).
>
> However, I really don't want to refactor the XML grammar
> half-heartedly. Currently, the grammar works perfectly, and the tests
> should reflect that.

Smart move - one battle at a time.

> If my schedule is freed up a bit in the future (I have recently taken
> on and am currently working on something of an ambitious scope), I
> would implement the following changes to Serialization archives:
>
>  * Rewrite all the existing archives using Spirit 2.x (Karma for
>    output archives, Qi for input archives).
>  * Create a new interface, allowing users to write new archive types
>    using Qi and Karma.

A more interesting task would be to make karma/qi archive.  Using
the serialization interface, one could generate the karma/qi code that
would implement a text editor for the created archive.

> I could make it work better and perform faster at runtime and compile
> time, but the best way to do that would involve ripping up a lot of
> the existing archive internals.

As I remember, aside from creating the grammer, there was hardly
any code to write so I'm not sure what archive internals refers to.
In any case, I'm please that someone has taken responsability for this.

This same set of problems - compiler quirks, stack overflows at
compile time, etc ocurred with the original version.  These were
handled by a few minor re-factorings in the grammer.  The original
grammer was derived from Dan Nuffers XML grammer which was
part of the original spirit package.

> I'll contact the test runner. IMHO, timeouts should not have a fixed
> value; instead, new tests should not timeout at all on their first
> run, but the time
> they take to run should be recorded. The runtime duration of each run
> after the first should also be recorded. This would allow a range of
> predicted durations
> to be computed, and the high value in that range should be used to
> compute a timeout duration. This would also be helpful because it
> could show Boost TMP maintainers how changes in their libraries
> affect compile times.

It looks to me that this time overflow should only occur during the
build of the library - a one time thing.  That is, it wouldn't have to
be increased for each test.

Robert Ramey