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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk