[boost] Re: boost-build and version numbering

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 1.31.0.1 for my first patch to 1.31.0 etc 
so hopefully shouldn't conflict with boost numbering systems.

Cheers

Russell

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
>>
>> 1.30.2
>> 1.31.0
>>
>> 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 1.31.0.1 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[1]) ] ;
>     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.
> 
> HTH.
>