Subject: Re: [boost] [bcp] Bcp namespace rename causes compile errorsonmultiple libraries (type_traits, range, spirit, foreach, regex, iostreams) in 1.43
From: Cliff Green (cliffg_at_[hidden])
Date: 2010-05-28 13:21:49
> Thanks for the report - the namespace substitution was tested, but we
> don't have automated tests for it - in fact full tests would be rather
> difficult to contrive, because as well as requiring that the modified code
> compile on it's own, we should also require that two different Boost
> versions work side by side.
Since the problem I ran into were all compile failures, I'm guessing it's
relatively recent code added to the various Boost libraries. And while I
understand a full "system level" test takes some effort, I would think it's
not too hard to do a "perform bcp on all libraries, then perform the general
bjam that builds everything" (in essence, this is what I did). This would at
least verify that everything will compile after the extract.
But I fully understand the limited time and resources that are available. :)
> If you have the facilities to run a full test run after bcp substitution
> that would be great - the results would need to be compared to the results
> obtained without the substitution.
That would definitely be good - I have the facilities on at least a couple
of common compilers / platforms, but my available time might be limited. Let's
continue the discussion, and when I can get to this again (I'm guessing in
about two weeks), I'll see what I can do. (For now, my work project will
continue using 1.38.)
Independent of any contribution I can make, defining the verification
process is a good step (or just warning users of the bcp namespace renaming
facility that it has only been tested up to some particular date or
milestone). Since the Boost codebase is constantly changing, the
"verification" milestone will be moving as well.
The release process is probably "costly" enough already, so there might be
reluctance to add "perform the full bcp namespace rename testing step to
verify that nothing has broken" into the process. And of course, if
something is "broken", then there's the working with the developers to
change the code (and delaying the release).
Or, if the bcp "search and replace" can be made smart enough to work around
the source code issues found by me (and similar issues in the future), that
might be a better approach. A full "compare test results" would still be a
good step, but at least it would be expected that compile failures won't
> I will look into and try and fix all the issues you identify as soon as I
Thanks! Keep me in the discussions (if the coordination continues on the
Boost dev mailing list, I'll follow it there).
> Thanks for reporting these!
No prob, and as already mentioned, I'll help out as much as time allows.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk