Boost logo

Boost :

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2005-02-15 04:20:08

Somewhere in the E.U., le 15/02/2005


In article <ur7jj9not.fsf_at_[hidden]>,
 David Abrahams <dave_at_[hidden]> wrote:

> Hubert Holin <Hubert.Holin_at_[hidden]> writes:


> > My question was regarding wether or not we had specified a way to
> > put any existing conversion within the Boost directory structure. We
> > could upload these to a site such as yours, but perhaps proximity to the
> > libraries they are based on would be desirable...
> I'd put it under the Boost.Python library, but I think some people
> would be upset at Boost.Python's resulting apparent dependency on all
> the wrapped libraries.
> To get around that problem, I think we need a separate boost library
> called python-bindings. Or is it a non-problem?

      Well, a separate library has at least one problem: the need for
someone in charge of its maintenance. But it also has huge advantages:
it is a central gathering point and quality can be insured via
regression tests (perhaps part of the general regression tests carried
out before a new version of Boost is released).

      Furthermore, Boost.Python is likely to be the first place people
will be looking for these bindings, so perhaps an intermediary solution
is in order, if a maintainer for a separate library can't be found: a
page within Boost.Python's documentation linking to these bindings which
can be clearly marked as not being prerequisites for B.P, and the
maintenance of which (the binding's) is under the responsibility of
somebody else (the bound library's author or someone else). Or perhaps,
putting even less burden on B.P, a Wiki page with that info, referenced
from within B.P's documentation. Under this scenario, quality (of the
bindings) is not ensured, but perhaps bindings per se lie beyond the
purview of Boost, so this point does not matter much.


         Hubert Holin

Boost list run by bdawes at, gregod at, cpdaniel at, john at