From: Russell Hind (rhind_at_[hidden])
Date: 2004-08-12 03:06:26
Thanks, I'll have a play about. I do think it would be a good idea to
include the patch number in the file name, though. If 1.31.1 comes out
with a bug fix, I don't have a real way of telling if
boost_thread_vc71_mt_1_31.dll is actually 1.31.0 or 1.31.1 and depending
on the bug fix (header only lib or not), it could be important.
What I was actually looking for was to change it to a 4 build version
number for my patches such as 184.108.40.206 for my first patch to 1.31.0 etc
so hopefully shouldn't conflict with boost numbering systems.
Rene Rivera wrote:
> Wow! Sorry I missed this email... I was just cleaning out my inbox and
> noticed it...
> Russell Hind wrote:
>> Given boost uses version numbers x.y.z such as
>> The build system generated libs and stuff with -1_31 appended. I have
>> a few questions about this:
>> How is this generated?
> It's generated by the "common-variant-tag" rule in
> tools/build/v1/boost-base.jam - That rule is added to the requirements
> of the targets in the Boost tree, both directly by library authors and
> by the top level install Jamfile.
>> We wish to build our own version of boost (based on one of the above
>> releases, but with patches) so wanted to version it accordingly. The
>> obvious way would be for us to version it 220.127.116.11 so it is
>> differentiated from the official 1.31 release. Unfortunately, boost
>> only appears to support the x.y.z format.
> More precisely this is how I figure that out:
> local version-tag = [ MATCH "^([^.]+).([^.]+)" :
> $(version-number) ] ;
> version-tag = $(version-tag:J="_") ;
> Which means that we only support x.y format, as we assume that patch
> version are compatible with each other.
>> So we could number it 1.31.1 and hope boost doesn't release a 1.31.1.
> Seems dangerous, and I think there's a better way -- You could set the
> version to something like: 1.31a.0 (basically append some text after the
> "1.31" but before the ".0".
>> But I've edited boost/version.hpp to be 103101 and 1_31_1 and also the
>> jamrules file to be 1.31.1 but the build-generated libs are still only
>> post-fixed with -1_31. Where does the bulid system pick up the
>> version number so I can modify it for the build and would it be easy
>> to modify it to support w.x.y.z format so we don't run a risk of
>> coliding with boost versions?
> If you change the version number like I suggest above. You can then
> leave boost/version.hpp alone. And then you have two choices for setting
> the build system version number:
> * Add "-sBOOST_VERSION=1.31a.0" when you build, or
> * Change the BOOST_VERSION default in boost-root/Jamrules.
> That is set BOOST_VERSION in some way so that the default doesn't apply.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk