Robert Ramey wrote:
Well, it will take me some time to reconstruct what happened. Briefly, from memory:
a) I noticed that running the serialization tests most compilers emitted a warning "....deprecated - ? redirectored or ?" I forget.
Here's an example of PP code that does that: #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_actor.hpp") #elif defined(__GNUC__) || defined(__HP_aCC) || defined(__SUNPRO_CC) || defined(__IBMCPP__) # warning "This header is deprecated. Please use: boost/spirit/include/classic_actor.hpp" #endif #endif So, I do not understand how you got that warning, unless you are referring to code in the trunk at the time we were refactoring. Things have changed since then and to say that our work on migration to a new version was a failure based on early code is unfair.
b) Also the PGI compiler choked on the code which emitted the warning - preventing the build of the serialization library.
Ditto. I cannot understand why PGI will have choked on that code unless the Boost version is >= 1.38 and it emulated some compiler's IDs.
c) I figured - no big deal - I'll just tweak the "#include boost/spirit/.." as suggested by the warning message. Hey it is only a couple of files which use spirit. d) First problem was that I had included not boost/spirit.hpp - but some deeper level files like boost/spirit/chmod or ? whatever.
Might you be using some implementation details? I'll never know. I have no complaints on using just the public header files. All public header files are forwarded properly.
I had done this in the interest of saving compiler time an making it less likely that spirt code would confuse this or that compiler. In the course of figuring this out, I came on a really confusing sequence of #includes whold purpose seemed to make something automatic and invisible but left me baffled. I thik I changed things to include the "convenience header" e) The borland version of the serialization library builds with spirit 1.6x in the include path. With the header changes I was forced to make, that didn't work anymore.
Again, I'll never know why unless you report the exact problem. You can't just declare something broken without detailing the circumstances that lead to the problem.
f)I couldn't make the #includes conditional on the spirit version - because there is / was no manifest constant indicating the spirit version
I recall this was your *only* public complaint and we acted on it the very moment you mentioned it. This happened on the trunk.
g)I couldn't make the #include conditional on boost version since the boot version is always the latest and doesn't match the spirit 1.6x version i)I tried to use the lastest version of spirit with the latest version of borland but this fails to compile.
Again, without some more info, we are in the dark. We can't help you if you don't provide the info we need to fix what you claim is broken.
To top it off, the PGI compiler got over that spirit hump and tripped up on something else.
Ditto.
So the net result is:
a) The serializatoin library can no longer built for borland compilers. - a regression. b) The serializatoin library can no longer built for PGI compilers. - no change here.
I may have some details wrong in the above recollection. Of course had I known this was going to be such a hassle, I might have kept better notes and brought it up at the time. But then again if I had known how much time was going to be wasted on this, I would have just ignored the "deprecation" warnings. I'll probably just back out these changes and do that.
But to go back and verify all this with a minimal.cpp file is more than I have time for right now. Sorry.
Robert, you cannot claim that our stragegy was a failure just because of that account! If you can't provide a minimal test case, then what you are saying is unfounded. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net