Re: [boost] [spirit] Where is SPIRIT_VERSION?

Subject: Re: [boost] [spirit] Where is SPIRIT_VERSION?
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-11-12 13:03:13

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