Re: [boost] [tools][bcp] using boost internally in other libraries

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-24 05:51:42

bjorn_at_[hidden] writes:

> On Saturday 24 September 2005 01:09, David Abrahams wrote:
>> Bjørn Roald <bjorn_at_[hidden]> writes:
>>
>> > - quality assurance of Boost itself
>>
>> Specifically?
>
> Again, and as I mentioned to John, there are allways room for
> improvement, but I do think the boost developers do a lot.  I bring
> this up because it is a genuine concern whenever you deal with
> sub-contractors or whatever, and it also apply to use of open
> source.

I understand the notion of QA in general, but I want to know
specifically what you think QA should look like, or look more like,
for Boost.

> Boost and or Boost Consulting could possibly make a more prominent reference 
> to QA efforts and procedures on their web sites.  At least have a bullet for 
> it an tie together the procedures you have with peer reviews, testing, 
> regression testing, bug tracking, change management, public developer mailing 
> list.  Then you can call this web page and its guidelines your Quallity 
> Assuruance Plan.

Okay, that's a great idea.  Boost Consulting's website desperately
needs an overhaul anyway.

>> > - stability of Boost API
>>
>> Yeah, there are no rules about it.  However, we generally avoid
>> breaking source compatibility.
>
> If the library is good enough, this is a risk many will choose to live with.  
> But it would be nice if library maintainers made ther _current_ view of how 
> stable the API was public.  Maybe on a scale used for all Boost libraries.

Usually it's possible to announce imminent destabilization well in
advance, so it would certainly be possible to have a status page that
described those things.

>> > - configuration management issues in general for us and our customers
>>
>> Such as?
>
> mostly a concern if we have to maintain other brances of boost than the 
> library maintainers on boost.org.

Ah.

>> > - platform support in Boost ( or if the platform support Boost if you
>> > like ;-)
>>
>> Sorry; what do you mean?
>
> Just trying to be funny, sorry...  the pun was that if boost is standard 
> conformant, then the platforms are to blame.   However, there are often some 
> truth in what I try to joke about. 

I understand, but I don't even understand the first part.  In what way is
"platform support in Boost" a concern?

>> > Ok, back to the example.  If MyLib have no intention of using Boost in
>> > the API, is there a way?
>>
>> There are several ways to maintain symbol isolation.  On Windows, it's
>> fairly easy: simply use a shared library and don't dlexport anything
>> involving boost.  On *nix, recent GCCs can give you control over
>> symbol visibility, so you can play the same kind of game.  Otherwise
>> -- and this is inconvenient at best -- you can do it by using dlopen
>> to load a shared library containing the boost symbols, and speak to
>> that library through one or more known entry points.  That approach
>> can be followed on Windows as well (using LoadLibrary) if symmetry
>> with *nix turns out to be more appropriate than using the platform
>> facilities.
>
> Use of dlopen/dlsym and the win32 equallents is sertainly possible.  Good 
> point -- I will think more about that one.  This could be appropriate if 
> internal use of boost can be statically linked into a loadable library, and 
> that module's services can be accessed through simple methods, alternatively 
> through some framework - component hook-up.  Interfaces to the module have to 
> be Boost less.

Yes.  I can even imagine a nice tool or library for wrapping these
interfaces up into isolated components so you and your clients don't
have to deal with the entry point/type erasure nitty-gritty.  That
might be an excellent candidate for a Boost library that supports
namespace renaming.

> David, you left out my text about use of bcp to rename the boost namespace 
> here, that is what I wrap up.

I didn't have much to say about it.

>> > I do not believe anything prevents me from going along this path if I
>> > decide to do so.  I am however interested in the boost developers
>> > attitude toward this approach, and in particular if this is something
>> > you will encourage and/or support.  I am willing to work on the tool
>> > support for this in boost or to maintain a modified bcp tool if that
>> > is more appropriate.
>>
>> I have mixed feelings about this.  One of the things some people
>> complain about when they look at the boost code is that the many
>> workarounds get in the way of understanding.  In fact, maintainability
>> was one of the issues you listed at the beginning.  So if we put in
>> facilities for namespace renaming, our code would get uglier and less
>> transparent.  Maybe that's not a big deal, as we've already stepped
>> off the "workaround cliff," but it is a concern for me.
>
> Ok, I agree with everything you write above, except the part about
> somebody falling off a cliff.  

:)

I just meant that we're probably fully committed to having ugly
workarounds, at least in some parts of Boost, so what does one more
hurt?

> But I feel like you missed one important point I tried to make.
> What I try to propose is something requiering no change in the way
> boost source code is written or maintained.  I propose tool support
> for a _production_step_ ensuring namespace renaming in a subset of
> boost selected with the bcp tool.  

Yes, I noticed that.  It's a really neat idea, but I have no clue
whether it's practical.  Actually I do at least have a _clue_.
Depending on the level of PP usage in a Boost header, it could be very
difficult to identify all the places that symbols need to be changed.
And even then a naive "replace the boost identifier" strategem is not
guaranteed to work unless we all maintain an agreement that "boost" is
never to be used as an identifier other than for the outer boost
namespace.  I'm not sure what other issues are lurking in there;
these are just the two that popped into my head immediately.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com