Solving boost version issues
Hello, I apologize in advance, if this contribution is slightly off-topic, but I assume that the discussed problem is of general interest for most boost users. Not rarely one stumbles across the problem that even your most favourite 3rd party library has an implementation error, and you need a fix for that. And the good thing: Those highly motivated guys have already found the error and fixed it - in cvs. Well, that is actually all very fine, especially if you are able to handle with cvs (who of the programmers can not?) and you could use this fixed version, but there remains one big problem: The 3rd party library has not been released and you want to prevent nasty effects, if your fixed version meets the older version - the have all the same lib names. OK, end of the scenario, I assume that I describe here a well-known and well-feared problem ;-) Actually everything is fine, besides...: I would like to modify the lib names and which place would be more reasonable than the bjam configuration? First, because the described problem just hits me in the moment concerning a boost fix and I would like to influence the current bjam, such that all libraries are build as usual, but with an additional user-defined (or even hard-coded(!) string constant (aka "build id") at the end of each name. I have to confess that I have little experience with bjam and I don't understand the way how I can modify the related file(s) to reach the wanted effect: I can only assume that one has to change the file Jamfile.v2, probably the "function" rule tag beginning with line 95. Please, is someone willing to help me in that situation? Second I would like to propose that the current bjam script is generally modified to allow the addition of such a user-defined build-id simply attached after the normal naming scheme described on http://boost.org/more/getting_started.html#Results libboost_date_time-gcc-mt-d-1_31-your_build_id.a with a new, to be defined bejam option, which allows such an addition. Sorry for the noise and thank you for your patience! With Greetings from Bremen, Daniel Krügler
Daniel Krügler wrote:
Hello, Second I would like to propose that the current bjam script is generally modified to allow the addition of such a user-defined build-id simply attached after the normal naming scheme described on
http://boost.org/more/getting_started.html#Results
libboost_date_time-gcc-mt-d-1_31-your_build_id.a
I think that's a good idea, but to make sure the right people see your message, you might want to repost in the boost-build mailing list. Regards, John.
John Maddock wrote:
Daniel Krügler wrote:
Hello, Second I would like to propose that the current bjam script is generally modified to allow the addition of such a user-defined build-id simply attached after the normal naming scheme described on
http://boost.org/more/getting_started.html#Results
libboost_date_time-gcc-mt-d-1_31-your_build_id.a
I think that's a good idea, but to make sure the right people see your message, you might want to repost in the boost-build mailing list.
The idea has been mentioned before. And is on my to-do list. Should be easy now that the BBv2 logic for the tags is reasonably modular. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Daniel Krügler <dsp@bdal.de> writes:
Hello,
I apologize in advance, if this contribution is slightly off-topic, but I assume that the discussed problem is of general interest for most boost users.
Not rarely one stumbles across the problem that even your most favourite 3rd party library has an implementation error, and you need a fix for that. And the good thing: Those highly motivated guys have already found the error and fixed it - in cvs. Well, that is actually all very fine, especially if you are able to handle with cvs (who of the programmers can not?) and you could use this fixed version, but there remains one big problem: The 3rd party library has not been released and you want to prevent nasty effects, if your fixed version meets the older version - the have all the same lib names.
OK, end of the scenario, I assume that I describe here a well-known and well-feared problem ;-) Actually everything is fine, besides...: I would like to modify the lib names and which place would be more reasonable than the bjam configuration?
First, because the described problem just hits me in the moment concerning a boost fix and I would like to influence the current bjam, such that all libraries are build as usual, but with an additional user-defined (or even hard-coded(!) string constant (aka "build id") at the end of each name. I have to confess that I have little experience with bjam and I don't understand the way how I can modify the related file(s) to reach the wanted effect: I can only assume that one has to change the file Jamfile.v2, probably the "function" rule tag beginning with line 95.
Please, is someone willing to help me in that situation?
Second I would like to propose that the current bjam script is generally modified to allow the addition of such a user-defined build-id simply attached after the normal naming scheme described on
http://boost.org/more/getting_started.html#Results
libboost_date_time-gcc-mt-d-1_31-your_build_id.a
with a new, to be defined bejam option, which allows such an addition.
Sorry for the noise and thank you for your patience!
This looks like something you might find addressed more easily on the boost-build list. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
Daniel Krügler -
David Abrahams -
John Maddock -
Rene Rivera