Hello, Recently I had a discussion with a colleague concerning the possibility to influence the resulting file names of the default boost output. This discussion was actually inspired by the outcome of thread "[thread] Keeping leak detectors still..." on 2006-07-11 where we had the situation of an inofficial patch which we would like to use. The problem is: How can/should I signal a patched boost version? According to the naming scheme described in http://boost.org/more/getting_started.html one could change the boost subminor version. Regrettably we found out that most programmers actually expect that such a number belongs to one of the *official* boost versions provided by http://boost.org/, (most probably because the naming scheme smoothly integrates). Now I had the idea of an optional "build id", which is a well-known tool in many projects to signal a given state or "snap shot". The very advantage of a build id - which's format is usually not fixed, but typically is a string of numbers, letters and some file-name compatible characters like '-', normally without any white spaces and of arbitrary length - is, that it accentuates and differs very strongly from the regular pattern of the subdivided version number. Ideally it should be possible to define a kind of bjam constant, e.g -sBUILD_ID=string (I'm not a bjam expert and I hope that the above proposed name does not violate any naming policies of such configuration parameters), which would allow to explicitly set build id for a bjam build. I have no strong opinion concerning the exact position of that build id in a lib name, but probably the most resonable one would be just after the version number, e.g. libboost_date_time-gcc-mt-d-1_31_M20060721.a for -sBUILD_ID=M20060721 Does there already exist such a possibility to do that and if not: I would really appreciate such a general available "callback" for injecting a build id (a sequence of characters) into the final output. Standard behaviour would of course be, *not* to attach such id, but the possibility to do that via a userdefined program parameter of bjam would be fantastic! The problem is: If I would manually hack the boost bjam files to do just this, I could never update to the next boost version without fears, because I always would need to manipulate the new version also. Since I assume that this request is of general interest for the community I would like to humbly ask for support of it. What do you think? Any chances for that idea? Or better ones? Greetings from Bremen, Daniel Krügler