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? 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. So we could number it 1.31.1 and hope boost doesn't release a 1.31.1. 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? Thanks Russell
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. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
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.
participants (2)
-
Rene Rivera -
Russell Hind