id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
691	Bjam build should support attachment of individual build ids	daniel_kruegler	Vladimir Prus	"{{{
The Boost library has very high reputation due to its
code quality and is used in many companies and
organizations as part of their own production code.
Bug fixes are usually rarely necessary, but due
(naturally understandable) longer release cycles, they
tend to accumulate slightly, which raises the
propability that individual organizations decide that
they would like to use a non-official release version
of boost:

- They use selected parts from the current development
code.
- They use proposed fixes which were the result of
newsgroup discussions.

Due to these practices there exist need to extend the
current naming scheme of boost libraries to allow the
attachment of individual build id's to the current lib
names, e.g. instead of the current example from
http://boost.org/more/getting_started.html#Build_Install:

libboost_date_time-gcc-mt-d-1_31.a

I propose to extend the bjam action table with the option:

-sBUILD_ID=string

If this option is not used, the current naming scheme
applies as usual, but if the proposed option is used,
e.g. with

-sBUILD_ID=M20060727-vgf3

the above output file is named to

libboost_date_time-gcc-mt-d-1_31-M20060727-vgf3.a

The very advantage of this proposal are:

- Popular build id naming schemes tend to point
themselves out of the regular version pattern and allow
better discrimination from official boost release
version. Build id do have a well-known tradition in 
many popular software products.
- The proposal is non-intrusive and allows tagging
boost output according to company-specific naming
schemes. Users don't need to manually ""hack"" the
current bjam input file to enforce such naming scheme.
Users not interested in this scheme will not be
influenced by this extension.

}}}"	Support Requests	closed		None	None	Showstopper	fixed