Re: [Boost-users] run_test parameter not working (Boost Unit Test Framework)
Hi Gennadiy,
Will this be released as a patch for 1.35 or just will be just released in the next version of boost?
Will you please specify which file was fixed so that I can download myself and rebuild?
thanks
Marc
----- Original Message ----
From: Gennadiy Rozental
Hi,I've downloaded the 1.35.0 source and built my own boost libraries in Redhat 5.1 withthe intention of using the boost unit test framework. However, I noticed that the run_test parameter is not working.Has anyone experienced this and came up
I believe this is fixed in svn. Therer was incorrect ifdef that disabled the functionality on most platforms. Gennadiy _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Marc Oliver Castañeda
Hi Gennadiy,Will this be released as a patch for 1.35 or just will be just released in the next version of boost? Will you please specify which file was fixed so that I can download myself and rebuild?
This hopefully is going to be part of next release (not sure if I need to do anything for this to happened). The file at fault is unit_test_main.ipp. Take trunk HEAD - it should be fine. Gennadiy
Hi Gennadiy ! On Wednesday 23 July 2008 19:34:31 Gennadiy Rozental wrote:
This hopefully is going to be part of next release (not sure if I need to do anything for this to happened).
Well, unfortunately not :-(( You had to to merge the libs to the release branch according to http://svn.boost.org/trac/boost/wiki/ReleaseSchedule and http://svn.boost.org/trac/boost/wiki/ImprovingPractices And at the former page we have: July 3, 2008: branches/release closes for routine minor changes and fixes. Still open for serious problem fixes. So, it's too late for 1.36.0 :-(( Well, I think you have to ask to release manager for permission to merge this one. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Juergen Hunold
Hi Gennadiy !
On Wednesday 23 July 2008 19:34:31 Gennadiy Rozental wrote:
This hopefully is going to be part of next release (not sure if I need to do anything for this to happened).
Well, unfortunately not ( You had to to merge the libs to the release branch according to http://svn.boost.org/trac/boost/wiki/ReleaseSchedule and http://svn.boost.org/trac/boost/wiki/ImprovingPractices
Not sure how it's an improvement. What is being used as base for release brunch? Why not pick up library trunk state automatically if it's passing all tests?
Well, I think you have to ask to release manager for permission to merge this one.
Not sure I'll have time for this double work. Anything that in a trunk can be (and should be) released. Gennadiy
Hi Gennadiy ! On Thursday 24 July 2008 22:28:32 Gennadiy Rozental wrote:
Juergen Hunold
writes: Well, unfortunately not ( You had to to merge the libs to the release branch according to http://svn.boost.org/trac/boost/wiki/ReleaseSchedule and http://svn.boost.org/trac/boost/wiki/ImprovingPractices
Not sure how it's an improvement. What is being used as base for release brunch? Why not pick up library trunk state automatically if it's passing all tests?
Please don't shoot the messenger :-))
Well, I think you have to ask to release manager for permission to merge this one.
Not sure I'll have time for this double work. Anything that in a trunk can be (and should be) released.
Well, that is how most projects successfully work. But I don't comment on that decision any more... Thanks for adding the docs ! Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
On Jul 24, 2008, at 4:28 PM, Gennadiy Rozental wrote:
Juergen Hunold
writes: On Wednesday 23 July 2008 19:34:31 Gennadiy Rozental wrote:
This hopefully is going to be part of next release (not sure if I need to do anything for this to happened).
Well, unfortunately not ( You had to to merge the libs to the release branch according to http://svn.boost.org/trac/boost/wiki/ ReleaseSchedule and http://svn.boost.org/trac/boost/wiki/ImprovingPractices
Not sure how it's an improvement. What is being used as base for release brunch? Why not pick up library trunk state automatically if it's passing all tests?
AFAIK, the trunk _is_ what is used to base the release branch, from some cut-off point the release manager decides, and informs the group about. Each library's maintainer should merge the readiest, but non- revolutionary, revision of his/her library around that cut-off point back into the release branch (if the cut-off point's revision is insufficient). If you been making either evolutionary changes or a non-bleeding-edge revolutionary change, you should merge in the last revision of those changes after the cut-off. If you just made a bleeding-edge change (i.e. you don't know all the consequences to all the platforms and/or fixed most of them), you should merge in the revision before the cut-off that is before the change. Just grabbing off the trunk is irresponsible. Even if we keep the trunk release-ready, which we are striving for, trunk-grabbing requires that we PROVE the release-readiness. That requires that we build & unit-test on every check-in (and reject failures). AFAIK, a Boost source tree requires hours to test, even if we run each platform vs. compiler/linker vs. configuration-parameters combination in parallel. This would back up our check-in times considerably, which is impractical. That's why we need a separate scratch space for our release trees, for proper clean-up and testing.
Well, I think you have to ask to release manager for permission to merge this one.
Not sure I'll have time for this double work. Anything that in a trunk can be (and should be) released.
And that would be problematic for anyone who deliberately skipped the cut-off to add bleeding-edge changes (like me and Boost.Integer). We would have to warn the release manager to back out stuff, including any dependencies on the new stuff. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker
AFAIK, the trunk _is_ what is used to base the release branch, from some cut-off point the release manager decides, and informs the group about.
Is it written somewhere? If it's true - I'll be fine.
Just grabbing off the trunk is irresponsible.
I meant at release cut-off point. Further fixed must be merged.
Well, I think you have to ask to release manager for permission to merge this one.
Not sure I'll have time for this double work. Anything that in a trunk can be (and should be) released.
And that would be problematic for anyone who deliberately skipped the cut-off to add bleeding-edge changes (like me and Boost.Integer). We would have to warn the release manager to back out stuff, including any dependencies on the new stuff.
I meant Boost.Test specifically. Boost.Test is almost always release ready. The rest of your comment I do not follow. Gennadiy
participants (4)
-
Daryle Walker -
Gennadiy Rozental -
Juergen Hunold -
Marc Oliver Castañeda