Joel de Guzman wrote:
Robert Ramey wrote:
my machine but the directory structure is different. To
Not true! The directory structure was never changed.
Well, something is different. The build failed on some compiler (PGI I think) and it was related to this change. I looked through what was going on (a waste of time) and concluded that chang
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:
Doesn't work on all compilers. That's why I made the change.
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.
LOL - If that were the case, I wouldn't have changed anything
No way to know. How
No need to know.
I realize that this is the intent. It just work in all cases.
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.
I realize that, I'm just letting you know that it was failure.
It's not an easy task, mind you. A lot of neurons were employed until we came up with the best practical approach.
The problem is that you tried to make it too clever. So it works in almost all cases. However, if it fails in just one case, then I have to start spending time to investigate. First there is the baroque directory structure. This creates a problem for me in that I never included just "spirit" but rather the lower level directories in order to included just the facilities that I used. So then I had to spend time to figure out what I should include. Then I come accross new names, etc. so then I have to try to "know more beyond the name(s)." which takes more time. The most irksome part of this is that it is totally unnecessary.
Then again, all these does not have anything to do with naming.
Actually, this thread started with the idea that spirit::karma (or whatever it is) should be considered as an alternative to including a separate logging library in boost. This raised 2 issues 1) choosing one logging library implementation for boost over another proposal by default rather than through the review process. 2) the fact that no one looking to see if boost had a logging library would be expected to find "sprite::karma". This wastes time of anyone preparing a logging library for submission. Robert Ramey
Regards,