On Sat, 2005-02-26 at 07:13 -0500, Todd Vierling wrote:
> 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

I was thinking about installing bjam on its own package (rather than
mixed with any headers) because it may be useful on its own, without
any specific boost stuff.  It may be of very limited use now, but
it looks like Boost.Build v2 aims to be something fairly complete and
maybe usable outside of itself (though I don't know for sure).

Anyway, what do you mean with a "helper script"?  Something like a
bjam.mk file that defines the right variables (and possibly some
do-build and do-install targets) to easily call bjam?  (I've stuck
that stuff in boost-build's buildlink3.mk file.)

> - 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.

Yes, it seems a good organization (lots better than the current one).
But see below.

> >  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.

Indeed! ;)  Everything will be easier this way.

> > - 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.

Ok.

> >   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.

Yep, more or less what the existing toolset.mk file does, right?  I've
kept all the logic together in the boost-build package.

WRT the library names, I've enabled --layout=system in the build, which
seems a reasonable choice.  This installs libraries with
toolset-agnostic names (ok, only with the -mt suffix).  After all,
it is impossible to install two different builds of boost in the same
tree, even with pkgviews.  And this will simplify PLIST handling.

But if we still want to keep the names, I think we do have to install
non-versioned names as symlinks.  Otherwise, building stuff outside of
pkgsrc will be a PITA (more than it's now).

> > - 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.

Hmm yes... the thing is that I'm writing a program in which I'm using
Boost.  The program is very small, and it uses just one or two binary
libraries from Boost.  In such cases, I think it'd be nice if installing
this little package didn't need a huge dependency; specially on old
computers, where compiling C++ code is sloooow.

Furthermore, the binary libraries are quite independent, so they might
be shipped separately.

A counterargument, though, is that these libraries (except python) do
not need any extra dependency, so splitting them is of little use
(except for build time and disk usage).

But I don't care that much about this point.  I think I'll go with your
suggestion...

> > - 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-)

Hehe, true.  Ok, so I guess I'll have to guess what results from the
autoconfiguration make the build to fail (they are related with our
lack of wchar support, IIRC).

Thanks for the reply,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/