Re: boost-mpi package

[Brook Milligan <brook%nmsu.edu@localhost>]

On Fri, 24 Feb 2012 18:34:13 +0100
Thomas Klausner <wiz%NetBSD.org@localhost> wrote:
> I still think that splitting it in multiple packages is the correct
> solution. When building for ftp.netbsd.org, we can only choose mpi or
> not-mpi with the solution you suggest, at build time. With split
> packages, binary packages exist for both options and the user can
> decide.

A perfectly good reason and good rationale.  However, my knowledge of
bjam is insufficient for me to split out individual libraries and tell
them about dependencies that have already been built by other packages.
If there is anyone who knows bjam well enough to do that and is willing
to work on these packages, then please step up.

There are four libraries involved: Boost.Serialization (serialization
and wserialization), Boost.MPI (mpi), and Boost.Graph_Parallel
(graph_parallel).  The dependency graph for these is as follows:

        serialization <- mpi <- graph_parallel
        wserialization (not a dependency for anything)

Additionally, bjam allows control over the building of these libraries
but always satisfies dependencies:

--with-serialization: builds both serialization and wserialization
--with-mpi: builds mpi and serialization
--with-graph_parallel: builds graph_parallel, mpi, and serialization

This raises the first question: should all of boost-libs depend on MPI
by default?  My inclination is no, but I would like input.

If so, then an MPI dependency can be added to boost-libs and the two
new libraries (mpi and graph_parallel) will be built.

If not, then I think we need to split boost-libs as follows:

- boost-libs: remove serialization and wserialization
- boost-serialization: provides serialization and wserialization
- boost-mpi: provides serialization, wserialization, mpi,
  and graph_parallel

The latter two would conflict with each other.

So, which of these two pathways (or some other) makes the most sense?

Cheers,
Brook