Boost logo

Boost :

Subject: Re: [boost] Proposal: Add Loki Library's SafeFormat to Boost:
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-01-02 12:15:29


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,


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk