John Maddock said:
Bjørn,
A very interesting read, thankyou for raising this.
thank you.
- commercial support for our use of Boost
Just out of interest what kind of support would be most beneficial to commercial users?
Hard to answer in a few words, but my personal feeling is that this is much less of a concern for developers than it is for managers. Many managers find it hard to trust something when they have nobody they can hit if things are not working out as expected. Personally I have experienced strong skepticism for ACE/TAO go away when a legal entity stated that they sell and support the tools commercially. You can also then assess this company and its solidity, which is a game they know how to play.
- quality assurance of Boost itself
We're working on improving our release stategy, but any ideas on how we can do better would always be appreciated.
I will keep that in mind, I know you are doing a lot and that is highly valued. Also if I may ad, your approaches to testing has been a good source of inspiration and solutions to me and my co-workers. The challenge may not be as much to do better, as there always is room for, but maybe to make potential users better aware of what is done.
- stability of Boost API
That one is tricky, Boost is meant to be at least a little experimental.
I know -- in a post some time back I mentioned that a sort of index of how stable the maintainer and boost developers considered the various accepted library APIs to be might be helpfull. I would have an easier time getting accept for using a library considered more stable by the developers. This information is not available to me now.
- maintainability of Boost source code
That's a genuine concern, we have some code that can probably only be maintained by the folks who wrote it, and that's not good at all.
This is closely linked with commercial support. If a product is commercially supported by somebody I trust, then I might not care. But if it is not, I will have to consider the possibility of having to fix problems myself. If I have no reasonable way of understanding the code, it spells TROUBLE.
referenced from MyLib API. How can this be achieved? I have concluded
unpractical at best. This needs to be designed into all of boost for
<boost/xxxx.hpp> directives which does not refer to the wrapping
The general idea is that there are no references to symbols in the boost namespace between any MyLib libraries, nor in any header files in or that accessing boost trough namespace wrapping header files are this to work, and I do not know exactly how. The main challenge is #include headers.
I think there are two issues here:
1) Side by side binaries: requires that symbol names in binaries are unique to the Boost version being used, or even the library being compiled. Requires that the Boost namespace be customisable to something other than "boost". I guess we could do what STLport does and make the namespace a macro throughout Boost,
This would give one source, better than mingling with source code. However I am not aware if a macro is a good solution for this, does that work well for STLport?
or we could do as you suggested and do a search and replace on "boost", unfortunately the latter is likely to be error prone at best.
agree that there are issues with a search and replace strategy, however it may be feasible.
2) Side by side headers: only needed if the library exposes it's Boost dependency in it's public API's. Requires that the #include's get fixed up to include via a path other than boost/. This is not as easy as it sounds, because there are some #include's in Boost that proceed via macros.
I do not understand exactly what you mean with "proceed via macros". Could you point me at an example please?
Macro-ising this in the Boost source is probably not going to be easy or acceptible, but I'd be interested in what other folks feel.
One benefit of placing all this inside the Boost source directly is that we could regression test it just by running some of our tests with BOOST_NAMESPACE (or whatever it's called) defined to something other than boost.
maybe even test a library's integration in in the "std" namespace, there will be some name conflict issues with the various standard libraries, but it feels like a tempting thing to try. Try the feel of your proposed library in the std namespace... demonstrate integration with std library implementations -- who knows.
<boost/xxx.hpp> directives to #include <Mylib/boost/xxx.hpp>. This would make a buildable library which would not share symbols with other versions of boost. The result is a branch or clone if you like of Boost that can be used with the same effect as if we actually had a Cat1 boost >library. There is however serious problems here. Any management with common sense would say.... hey.... stop. The prospect of undertaking >maintenance of a branch or clone of Boost does not make much sense --- So, the only way
An alternative is to replace all references to boost namespace with e.g. MyLib::boost namespace in the boost source code and change all #include this would work is to make it possible to maintain the >library in the boost community and somehow make the translation to the MyLib/boost namespace a pure production step. In configuration >management terms this means that the original or possibly slightly patched boost source code is under configuration control along with a tool-chain >used under MyLib system build that transforms the boost source tree to the form used internally. This is where I started looking at Boost >tools/bcp.
It would probably be easier (and more reliable actually) to change "boost" to "mylib_boost_1_33_0" or whatever rather than using nested namespaces, would that be an acceptable alternative?
Yes, I think I would just use "mylib_boost" since the version would be implicit through my configuration management. Hopefully my customers are only using one version of MyLib ;-) . But thats really their problem, not mine. Nesting would however be nice since we internally could write #using namespace MyLib; and then write boost code as everybody else. -- Bjørn