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