[Boost-build] A number of issues with boost.build in 1.36.0

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

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

-- 
Philipp Thomas, Architecture Team, SUSE Linux Products GmbH