Subject: Re: [Boost-build] A number of issues with boost.build in 1.36.0
From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-10-29 12:27:59
On Wednesday 29 October 2008 18:03:32 Philipp Thomas wrote:
> I don't have the time to learn the innards of boost.build,
> specially given that boost is the *only* package that uses bjam and
> therefore the knowledge gained here won't help me with the rest of my work.
Somewhat combative start :-)
> The upcoming 1.37.0 is no option, as packages for OS 11.1/SLE 11 are frozen
> and can't be updated and as boost is a base package (our package handling
> library uses a number of boost facilities), there is no chance for change
> this late in the release cycle. So I would *really* appreciate getting help!
> I guess that packagers for other Linux distributions would also benefit from
> the answers.
> The issues listed in order of priority are:
> 1) library name and soname generation.
> Two options seem to be offered by boost.build, either layout=system or
> the default. Neither of them is usefull for us, given that neither
> results in a usefull file name and therefore soname.
> Given that I splitted off subpackages for each shared library (for more
> fine grained dependencies resulting in less required disc space) and our
> shared library policy requiring that the names of such packages have
> to match the soname, the default
> <toolset>-<threading>-<major_minor>.so.major.minor.patchlevel leads to
> rediculous package file names. It also would make updating the compiler
> in a released distribution impossible as that would require also issuing
> updates for boost and all packages depending on boost.
> Using layout=system isn't an option as that also results in sonames that
> aren't really usable.
> So where and how do I have to modify build.boost in order to generate
> more usefull sonames and file names?
This is not boost.build, but C++ Boost's Jamroot, found in the root of Boost's
source tree. See the 'tag' function. You probably want to modify the else branch
if $(layout) = versioned
conditional. Note that in 1.37, toolset is no longer included when using system
layout. In 1.36, by removing <toolset> <threading> and <runtime> thread you get get
at library names like
I presume you actually want version in soname. Look how it's done in versioned branch:
result = $(result).$(BOOST_VERSION) ;
If you replicate this, you'll get:
or something -- which seems about right.
> 2) Passing compiler flags defined for a distribution.
> There are certain compiler flags that are used thoughout a distribution.
> In an autoconf environment these are passed by setting CFLAGS or
> CXXFLAGS before calling configure. Is there a way to also do so with
> boost.build, i.e. pass such flags via an environment variable? I
> currently patch builtin.jam and gcc.jam and to give variant release a
> new meaning but there has to be a cleaner and more easier way.
Pass cflags=-foo cxxflags=-bar to bjam invocation. Note that it's highly recommended
to invoke bjam directly, and not using configure/make. Note also that 1.36
has a bug, whereby if the value passed to this features has a slash, bad
things happen. If you want such values, grab this patch:
> 3) Library specific compiler options.
> Given the current Python API, the boost.python packages have to be
> compiled with -fno-strict-aliasing as the code breaks the aliasing rules
> in a number of places. As I haven't found a way to use that compiler
> option only for boost.python, I compile the complete boost package with
> that flag which disables some compiler optimisations. So I would
> appreciate if somebody could explain me how to use comiler flags only for
> those packages that really need them.
Go to libs/python/build/Jamfile.v2, and change:
: source-location ../src
: source-location ../src
: requirements <cxxflags>-fno-strict-aliasing
> BTW, we do have the public openSUSE build service that allows building
> packages for most Linux distributions so it would be possible to use it to
> offer packages for them. For this it would be best to have someone
> knowledgable with both boost and boost.build to team up in order to maintain
> such a package. On which mailing list should I ask?
I'm not sure what is this and what's involved. Are you saying it's a way to build
boost packages, straight from SVN, for various Linux distros? This sounds
useful, but I'm not sure what "maintain" means. Is this not supposed to be
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk