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 13:14:09
On Wednesday 29 October 2008 20:07:16 Alexander Sack wrote:
> On Wed, Oct 29, 2008 at 12:27 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
> > 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
> This is also done in the current 1.34.1 FreeBSD port as well, removing
> the tags above will yield a more standard naming convention in
> addition to layout=system.
I think we talked with Steven about making such a change, but I don't remember
if we've agreed.
> > 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.
> Odd ball question, but why does the Boost.Build by default yield
> somewhat non-standard name conventions for libs on *NIX platforms by
> default? I'm not attacking anyone here I'm just curious what the
> history has been? And before some asks me what do you mean by
> *somewhat non-standard* please do an ls /lib or /usr/lib to and
> compare that to "libboost_math_c99-xgcc40-mt.a!!!"! etc... :D
This predates me. I think it comes from well, windows. There's folks
want many variants to be built by default, because they are not link-compatible,
and because windows developers tend to use different variants depending
on preferences, project etc. So, Boost.Build V1 was modified to produce several
variants and decorate them. V2 did exactly same.
I do not think this behaviour makes sense on linux by default.
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