[pkg-boost-devel] Packaging RC_1_34_0 and/or whole Boost distribution

[Dean Michael Berris]

Hi again Steve!

On 1/19/07, Steve M. Robbins <steve at sumost.ca> wrote:
> On Fri, Jan 19, 2007 at 06:32:38PM +0800, Dean Michael Berris wrote:
> >
> > This assumes that /path/to/boost/root contains a Jamfile.
> >
> > BTW, I am using BBv2.
>
> OK.  Despite having packaged boost in the past, I have little actual
> experience with it.  And no experience with Boost.Build.  While I
> can't speak for the other boost maintainers, your explanation has gone
> right over my head.  ;-)
>

Oh, okay. :D

> It sounds like you are suggesting that libboost-dev ought to be
> installing a Jamfile somewhere.  Given that we "install" the boost
> headers and library files, is the Jamfile that comes with the boost
> source workable or is it a Jamfile that needs to be modified to
> reflect the install paths (/usr/include/boost and /usr/lib)?  If the
> latter, could you provide a working example?
>

I initially thought that having the Boost root Jamfile(.v2) available
somewhere will be enough to enable the above example, it seems a bit
more complex than that.

There are two reasons why this is complex:

1) This Jamfile(.v2) is what the Boost distribution uses to define the
targets to be built. While these targets seem only useful during build
time, it also provides the compiler/build specific flags which is
pretty hard to figure out in other projects. This Jamfile defines the
aliases to the targets which saves users (like me) the trouble of
figuring out that I should be linking to
"libboost_serialization-gcc403-mt-st" in my project.

2) Since libraries like Boost.Filesystem are independently built and
packaged, the Boost distribution root Jamfile wouldn't have the
appropriate files available to make the targets valid (and built).

I think there are other reasons, but I think this is something I'm
going to have fun figuring out. :) Maybe a different solution should
be required, and I'll explore the options.

One that comes to mind is to have the build Jamfiles of the Boost
libraries (or at least those that require building) be installed along
with the headers in the -dev packages. Putting them in a location like
/usr/share/boost-build/libs/ should be alright, having a Jamfile.v2 in
/usr/share/boost-build/ which aliases to the appropriate targets in
the appropriate libraries -- the postinst and postrm scripts can then
adjust the Jamfile accordingly once the -dev packages are installed
and removed respectively.

I'll try out this approach, and detail my experience. :)

>
> > For the meantime I've chosen to package the boost libraries that my
> > projects require along with it using bcp -- but that's not the most
> > elegant solution.
> >
> > The question then would be if it would be possible if there was a
> > package which contains the whole boost distribution? Something like
> > boost-all that contains a complete Boost distribution?
>
> The feeling of the initial packagers is that few projects would use
> more than a few of the boost libraries.  Rather, you need to depend on
> libboost-dev, plus a handful of others like libboost-filesystem-dev,
> etc.
>
> What you propose is certainly possible.  My suggestion is that you
> write up a wishlist bug and argue the case there.
>

This certainly sounds like a good idea. Though I won't argue with the
initial decision, what I'm worried about now is that with the current
trend of development in Boost libraries, inter-dependence between the
newer libraries and the sheer number of new libraries being accepted
and made part of Boost, it's going to be pretty hard to maintain
separate packages for each.

Although some of the newer libraries are header-only libraries, this
shouldn't be too much of a worry. But for libraries where binaries
should be built (filesystem, serialization, thread, etc.) and have
funky names with compiler and flags information, a better way of
referring to them in Boost.Build -dependent projects would be very
much appreciated.

So I think the question now is, to which package should I file the bug? :D

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459