Status of devel/boost upgrade

[Alexander Churanov]

2009/4/1 Dmitry Marakasov <amdmi3 at amdmi3.ru>:
> * Jeremy Messenger (mezz7 at cox.net) wrote:
>
>> No need bsd.boost.mk over that small stuff. How about resolve conflict for
>> real by split boost and boost-python by have boost only install non-python
>> stuff and boost-python install only python stuff?
>
> That of course would be harder and more interesting, maybe I gotta dig
> into it.

Hi folks!

I've already did it about a month ago. Currently I'm testing the
solution. There are two ideas about splitting boost:

1) Split it into bjam, source-libs, shared-libs, python-libs and docs.
This is what was actually done by me.
2) Split it into bjam, docs and a separate port for each library. This
needs discussion.

If you are interested, you may download sample ports from
http://alexanderchuranov.com/boost-port/ The most recent tarball
contains a set of alternative non-conflicting versioned ports for
boost. They may be installed in addition to existing devel/boost. The
'source-libs' are header-only libraries that do not need compilation.

For now I've found a single flaw in the latest set of these ports:
devel/boost-python-libs-1.38 conflicts with devel/boost, because they
install Pyste in the same place. Please, note that the flaw is only
about the conflict of versioned port and non-versioned, if we would
break non-versioned, system-layout boost as we currently have into
parts, then there is no flaw at all.

I didn't started a mailing thread on this topic, because there are
tasks related to devel/boost that are not yet completed: updating to
1.37 and then to 1.38.

Splitting boost into parts have following benefits:

1) Shorter time of installation/updates from packages.
2) Fine-grained selection of what's really necessary.
3) Simplified dependency tracking for other ports that depend on boost.
4) No more issues like conflict of devel/boost and devel/boost-python

There are also drawbacks:
1) Time to build complete boost from ports is increased, because
boost.org provides a single source package and it gets decompressed
several times.
2) The number of ports is increased.

The questions are:

1) Should we break boost into parts?
2) Should we break boost into "jam', 'source-libs', 'shared-libs',
'python-libs' and 'docs' or into one port per library?

If folks agree on splitting boost into parts, I'll be glad to finish it.

Sincerely,
Alexander Churanov,
maintainer of devel/boost