Subject: [Boost-build] A number of issues with boost.build in 1.36.0
From: Philipp Thomas (pth_at_[hidden])
Date: 2008-10-29 11:03:32
In finalizing 1.36.0 packages for the upcoming openSUSE 11.1 and SLE 11,
I've run into a number of issues where I need help from someone familiar
with boost.build. 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.
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 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?
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.
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.
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?
-- Philipp Thomas, Architecture Team, SUSE Linux Products GmbH
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