Bryce Lelbach wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
This is possibly better suited for the Spirit mailing list; however, I would like to get as broad an audience as possible here.
Recently, I ported the Boost.Serialization XML grammar from Spirit Classic to Spirit Qi. It was a pretty straightforward port, but I did expect an increase in the compile-time complexity of building the grammar. My reasons for this line of thinking were as follows:
* Spirit 2.x is fully attributed, while Spirit 1.x is not. This increases both the amount of data that we're dealing with (every parser/generator component must have an attribute), as well as adding additional compile-time checks and transformations which much be applied to that data. * To make Spirit fully attributed, Spirit 2.x uses frameworks that Spirit Classic did not use; Boost.Proto and Boost.Fusion (Fusion was created for Spirit 2.x, I believe), as well as a newer version of Boost.Phoenix.
To my knowledge, this new XML grammar is the first Boost component to use Spirit 2.x (Wave uses Spirit Classic). I believe this means this is the first time that software using Spirit 2.x has been placed under the scrutiny of Boost testing. Certainly, Spirit 2.x and the underlying libraries it uses undergo rigorous testing, but in my mind, testing a library and testing software that uses said library are two very different processes.
My question stems partially from the thoughts of Serialization's maintainer, Robery Ramey:
"Basically, my view is that we cannot ship something that doesn't work at least as well as the previous version."
My question for you:
Can software that uses Spirit Classic be ported to Spirit 2.x and retain the same level of compiler/platform compatibility without significant refactoring of the fundamental structure of the Spirit components of the software?
Please do note that I believe that there is room in the Serialization XML grammar for refactoring, and I certainly don't mean to imply that the authors of Spirit, Proto, Fusion or Phoenix are at fault here in any way.
I have encouraged and supported Bryce's undertaking on the assumption that the usage of the latest spirit would improve the xml_iarchive in every way including performance, maintainability and portability. This assumption was inspired and supported by the warnings that spirit classic was "deprecated" which seemed to suggest that it would be in our interest to convert to the latest spirit. The xml grammar used in the serialization library is very simple - what could go wrong? Well, It is starting to look like this assumption was wrong and I'm very disappointed. I feel the developer's of spirit have let Bryce down. I'm hoping the spirit developers can step up and follow through to realize the expections developed for this package. I'm hopeful that a couple of tweaks can reslove the issue - as I said the xml_archive grammar is a very simple one. Some of the issues seem simple as well - compile time with intel compilers, some hiccup deep in mpl which hangs up the IBM C++ compiler. And I'm more than hopeful that the spirit developer's can place a high priority on doing whatever is necessary to fix this. The serialization library is one of the highest profile users of spirit and an easy example and test case. Once, you put it out there, it's your responsability to see that it meets the expections you've created for it. I was very surprised (and disappointed) to find that Wave - a very convincing example of the capabilities of spirit does not use the latest spirit. Had I known that, I wouldn't have encouraged Bryce with his efforts. As I said, I'm hopeful that this is not too hard to fix - the spirit library tests are mostly OK (except for the IBM compiler which has to be resolved). Maybe you could start by adding a test which builds a grammar similar to the xml_archive grammar. Robert Ramey