On Sun, 20 Feb 2005, Julio M. Merino Vidal wrote:

> This proposal is very easily doable, but not with the actual threading
> related hacks present in pkgsrc.  ATM, the boost package installs binary
> libraries for everything, all with threads disabled.

Actually, I had started an effort to fix this, because the boost-python
package had to go threaded (due to all pythons in pkgsrc also being
threaded).  I had similar splitting thoughts, with the following
delineations:

- boost-build: bjam and headers, and a pkgsrc-supplied compile options
  helper script of some sort

- boost-libs: all libs except python in threaded form

- boost-python: the python library in threaded form

- boost-doc: documentation

Except for the bundling I used for "boost-libs" above, this seems to jive
with what you want to do, including the always-threaded option.

> - Is all this complexity really needed?  If so, why?  I don't see a
>   pthread dependency being a big deal.

Some people find it to be a big deal, but then, boost is not heavily used in
pkgsrc yet.  Python is used far more, and it's threaded-only now too.

>  We'd even make it a build-time
>   option for those systems where threading is available but they don't
>   want it.

I don't even see a need for an option.  Thread the world.

> - WRT thread_user.hpp... this is something very specific to pkgsrc, and
>   as already said, causes some misterious problems.  Do we want to keep
>   such custom thing?

No.  I didn't like the way I did that (to satisfy thread/non-thread desires)
and I'd be glad to see it go away.

>   FWIW, we are actually installing some unversioned libraries (without
>   1_31 in them), but they still keep the toolset in their names.

Yes, and we should keep some sort of toolset sanity check.  I suggest that
the proposed boost-headers (or perhaps a combined boost-build package
including the headers?) should include a .mk fragment that forces the
PKGSRC_COMPILER value to the same one used to build boost-build.

> - boost-python is inconsistent with the existing boost and boost-thread
>   packages.  What will happen when we are able build boost-python with
>   threading support?  Will we have a boost-python-thread package?

boost-python doesn't build at all because it needs threads.  So only a
threaded version should be supplied now.

>   By making each binary library a standalone package, this confusion
>   could disappear, because each package could install just one lib.

Well, I'm not entirely sure that's so useful; package glut can be annoying.
I had split out boost-python only because it separated the dependency on
python; all the other libraries could stand alone without extra
dependencies.

But if you really think this is the way to go, feel free; that's just my
opinion.

> - At last, on a not-very-related note, I'm curious about our invocation
>   of the configure script to generate user.hpp.  If I use the provided
>   header file, boost (1.32.0) builds just fine.

...On all platforms and toolsets?  Not that I doubt you, but that is a
typical point of argument for build-time autoconfiguration.  8-)

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>