Robert Ramey wrote:
Joel de Guzman wrote:
I wish you guys could appreciate how all this name changing makes things much more difficult for us poor library users.
The fact that names are in no way descriptive is another huge time waster. Just curious. How much time did you waste before you realize
Robert Ramey wrote: that Boost.Spirit was a parser? Can you explain why it is a "huge time waster"? IMO, it takes a second to know, while browsing http://www.boost.org/doc/libs, that Spirit is a parser.
Here are examples where time has been wasted.
All of a sudden, one some platform the serialization library fails to build. After a time, an investigation reveals that the #include <boost/spiritsomefile> get redirected in some baroque non-obvious way to something like boost/spirit/class.. or something like that. OK - I'll just tweak the library so that it includes the "classic" targets directly. Now, the library won't build for borland compilers. Turns
Spirit 1.8 never ever worked on Borland.
out that this compiler needs spirit 1.6x - which I have on
Yes, you need 1.6 for that.
my machine but the directory structure is different. To
Not true! The directory structure was never changed. The old headers will be deprecated (after a couple of releases [2, I think, starting from 1.37]), but not without warning.
top it off, there isn't enough information - or its not sufficiently obvious to find - to conditionally include the right stuff.
Not true! If you use a deprecated include and the warning starts to kick in (after Boost 1.38 I think), it will warn you and point you to the right file. Example: #if BOOST_VERSION >= 103800 #if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__DMC__) # pragma message ("Warning: This header is deprecated. Please use: boost/spirit/include/classic_dynamic.hpp") #elif defined(__GNUC__) || defined(__HP_aCC) || defined(__SUNPRO_CC) || defined(__IBMCPP__) # warning "This header is deprecated. Please use: boost/spirit/include/classic_dynamic.hpp" #endif #endif
Now, it looks like spirit is going to be "upgraded" how will this effect the current code?
You do not have to lift a finger. The new code is 100% backward compatible. No way to know. How No need to know. Unless you want to stay current. In which case you have various ways. 1) Simply tweak the paths 2) port to Spirit2.
much time have I wasted on this? I didn't keep track.
Does not have anything to do with naming. I see no connection. What you say above are totally different issues.
Not that it matters since we're not apparently done yet.
Here's a suggestion.
for your latest/greatest, put in the namespace boost::spirit and in directory boost/sprit
For your old version, with an incompatible API, put it in namespace boost::spririt_1_8 and directory boost/spririt_1_8.
and for your older version put it in boost::spririt_1_6 and directory boost/spririt_1_6
And include a macro BOOST_SPIRIT_VERSION with the version string or number
Leave the tests in the previous versions even though they are no longer being tested.
This would be really helpful and I don't think it would create much work for you.
It seems you haven't really tried to know more beyond the name(s). Except for spririt 1.6, our recipe is similar to what was done. "Classic" Spirit will not, I repeat: will not, go away anytimne soon. It is, and will be, in the namespace "classic". This is the technical rationale behind the "baroque" include paths. We want 100% backward compatibility while at the same time usher in the new generation. It's not an easy task, mind you. A lot of neurons were employed until we came up with the best practical approach. Then again, all these does not have anything to do with naming. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net