Joel de Guzman wrote:

Robert Ramey wrote:

...

In the new headers for spirit - I only find SPIRIT_VERSION in some "classic" file.

Basically I would like to compile something conditionally on SPIRIT_VERSION.

For classic Spirit, then it is: spirit/include/classic_version.hpp

For spirit2, there is none yet. And I'm not sure if we still need one. Historically, Spirit had its own release cycle. Now that Boost has a faster cycle, I am considering simply syncing to Boost's releases.

Tell me if you still think we need one.

Here is my problem: I included headers from spirit in order to parse xml created by the serialization system. I've been very pleased by the fact that once it was done, I've (almost) never had to back to it. This is just as well as I've by now forgotten everything about it. (increasing stack overflow as a function of aging brain). When major change where made in implementation, spirit 1.6 was left available for older compilers. This worked well. Users of Borland compilers only had to include the directory for spriit 1.6 headers and everything worked fine. Other compilers could use the recent implemenation without problems. The latest version of spirit redirects the headers. This fails on some compilers (I think pgi is one of them). So I figured no problem, I'll just tweak the #include avoid the redirection. Now even with spirt1.6x headers in the include path, the borland compilers fail. Using boost version is not a solution since some compilers require 1.6x even though they are using the latest version of boost. What I was looking for was a way to determine which version of spirt was being used to permit inclusion of the proper headers.

From my perspective - we're on spirit version 3 now. Unfortunately this is hidden from view. This makes thinks look "cleaner" but in fact hides differences which are relevant.

So I would like to see boost/spirit/... files and boost::spirit::... namespace mapped to 1.6 boost/spirit2/... files and boost::spirit::... namespace mapped to 1.8 boost/spirit3/... files and boost::spirit::... namespace mapped to ? This would mean that old code would continue to compile. Of course, boost wouldn't have to keep around the old versions or maintain testing on them. They could be archived separately. But we wouldn't have the issue of "which spirit are you using" or I got code which uses spirit and I get a raft of compile errors", etc. Personally I see no problem with the concept that when a library has a major interface change, its name also changes. In fact, I see that as a possitive change. I've noticed that the recording artist "formerly referred to as 'prince' is now to be referred to as "prince" again. Much simpler would have been prince-2 and prince-3. But no one has asked me for an opinion on this. Robert Ramey