On Sat, 26 Feb 2005, Julio M. Merino Vidal wrote:

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

Sure, though headers are trivial to install, and both are "build-time-only".
It's not really that important, though.  Whatever you like -- indeed, you
should probably assume MAINTAINER for the packages.  :)

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

I think it was instead for toolset link options, but I've forgotten some of
that plan now.  See below.

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

No, currently toolset.mk just converts PKGSRC_COMPILER to the boost value.

What I meant, which was related to the "helper script" idea above, was to
install a file for .sinclude to use, which would cause the build to fail if
the current PKGSRC_COMPILER value doesn't match the one used to build the
"everybody includes this" package (boost-build, boost-headers, etc.).

(Actually, it's that the last word of PKGSRC_COMPILER matches between the
boost infrastructure package and the current package; any words prior to
that are compiler helpers:  distcc, ccache.)

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