Sohail Somani wrote:
If you really want a poll, I do build boost myself. I can honestly say that I am not familiar enough with bjam even after a really long time tinkering with it (for what thats worth). Currently I build boost as part of the build on one project and use pre-built on another. I'm finding building it myself (using my own build system) is a lot better as I can apply stuff like profiling flags or changing compilers on a whim. To build boost I did need to make sure my build system could handle the same sort of things that bjam does (which it did).
Personally, I don't care if boost takes 2 years to release, so long as the release is solid and after being on this list, I don't think there is any fear of that.
It is a problem when Boost takes a long time between releases, such as the current 15 months so far since 1.33.1. Of course it is great that the releases are solid, but the time between major releases is also an issue. Most organizations will not deploy Boost from source code changes, currently on CVS. Furthermore organizations may want to use new libraries/features of Boost but, following the previous proviso, can not get them until a new release with them is ready. Other implementors of 3rd party libraries, which use Boost libraries under the cover, may be very reticent to make changes to their 3rd party library while fixes between releases are being applied to Boost as a whole, while testing is still ongoing, so they too will wait for the next release. Following Beman Dawes suggestion I think it would be advantageous to consider officially releasing individual Boost libraries and/or dependent groups of libraries before the wholesale release of all of Boost, although I understand the confusion this might cause with incompatible sets of libraries on an end users machine and the reticence Boost might have in doing so. But I think this problem could be largely overcome by some form of version tagging of each library, purely for the end users benefit, and by insisting that the release of any individual library, between full releases, always include the release of all dependent libraries which have changed since the last full release at the same time. Obviously this could not be done very easily for some libraries which depend on many other libraries, but for some of the libraries which are highly independent of others I think this would work well, and provide the ability for end users to pick up useful changes in a particular library before the next full release. I would say that new libraries added to Boost between full releases could also be distributed in this way so that end users would not have to wait for the next full release to use the new library. This would of course mean that someone might have version 1.34, let's say, of the full Boost on their machine but have version 1.34.1 of library X and version 1.34.2 of library Y etc. But if 1.34.1 of library X were guaranteed fo work with 1.34,2 of library Y and 1.34 of everything else, I see nothing wrong with this schema.