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-30 12:28:08

On Thursday 30 October 2008 18:36:58 Philipp Thomas wrote:
> 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.

Well, I hope boost.build is at least a little bit easier -- that C++ Build is
vastly easier that GNU toolchain.

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

OK. I'd actually think that MT should be always on, but I realize
that if you have ST and MT, then it will be hard to guarantee
backward compatibility.

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

Because we decided that nobody wants ST. After all, I don't know any other
libraries that comes in ST and MT flavours. Qt used to, in 3.* timeframe,
but it's MT-only now.

You can build both ST and MT versions of boost libraries by passing

        threading=single threading=multi

on bjam command line.

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

Do you mean this is RPM only? Of .spec is not the RPM .spec?

- Volodya