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: Philipp Thomas (pth_at_[hidden])
Date: 2008-10-30 11:36:58

Hi Vladimir,

* Vladimir Prus (ghost_at_[hidden]) [20081029 17:28]:

> Somewhat combative start :-)

I know and apologize :( I was so frustrated with boost.build when I wrote
that mail that I didn't really watch my language. It's just that it took
years to somehow master make and the autotools to be able to understand the
sophisticated machinery packages like glibc use and there I had lots of
collegues to ask. bjam and boost.build seem at least as complex and none of
my collegues can help.

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

Given that different versions of boost libraries should be binary
incompatible, I'd prefer libboost_whatever-<threading>-$(BOOST_VERSION).so,
but with the help above that shouldn't be a problem.

BTW, do you know why I only get the multi threaded libraries? In earlier
releases the multi-threaded libraries overwrote the non-threaded ones if you
used layout=system. And in 1.36.0 I still only get the multi-threaded
versions, irrespective of whether I pass layout=system or nothing.
 
> Pass cflags=-foo cxxflags=-bar to bjam invocation. Note that it's highly recommended
> to invoke bjam directly, and not using configure/make.

OK, so I'll copy the commands configure generates to my .spec.

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

Thanks a bunch, that should help immensely.

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

AFAIK not yet straight from SVN. You currently have to create a project
inside the openSUSE build service (obs for short) and have to check-in
tarballs, spec file and additional patches.
I helped a member of the ACE core team to do that for ACE, so I know from
experience what's involved :). The ACE folks maintain the spec file and
other files needed for building inside the ACE cvs and manually check in
those files into obs for a new release.

Most of the work will go into creating the .spec file, specially if you want
to build for multiple distributions and getting that working smoothly.
Further maintenance is needed for the spec file, for instance adapting to new
policies in the supported distributions or changes in the names of packages
boost needs. 

The OBS will ensure that once checked in your package is built 
and then rebuilt as soon as one of the packages boost depends on. This way
you can automatically get binary packages for all distributions the OBS
supports.

Philipp