Re: [boost] [spirit] New Header Structure [was Re: Proposal: Add Loki Library's SafeFormat to Boost:]

Subject: Re: [boost] [spirit] New Header Structure [was Re: Proposal: Add Loki Library's SafeFormat to Boost:]
From: Joel de Guzman (joel_at_[hidden])
Date: 2009-01-04 01:57:01

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