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

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
of the 

        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

        libboost_whatever.so

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:

        libboost_whatever.so.1.36.1

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:

        https://svn.boost.org/trac/boost/changeset/49127

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

        project boost/python
          : source-location ../src
          ;

to:

        project boost/python
          : 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
mostly automatic?

- Volodya