Re: [boost] Boost packages?

From: Edward Diener (eldiener_at_[hidden])
Date: 2007-04-02 07:56:53

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.