Subject: Re: Boost and threads
To: Julio M. Merino Vidal <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 02/26/2005 07:13:41
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
- 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
But if you really think this is the way to go, feel free; that's just my
> - 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 <email@example.com> <firstname.lastname@example.org>