[1.37] status/Jamfile.v2
Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, and it doesn't include the tests for several libraries. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/
Nicola Musatti wrote:
Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, and it doesn't include the tests for several libraries.
No, it's much worse than that. I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap Let me know if you need any help with this. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/
Hallo, sorry to insist, but I think this should go in rather sooner than later. Cheers, Nicola Nicola Musatti wrote:
Nicola Musatti wrote:
Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, and it doesn't include the tests for several libraries.
No, it's much worse than that. I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
Let me know if you need any help with this.
Cheers, Nicola
-- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/
On Sun, Oct 19, 2008 at 3:11 AM, Nicola Musatti <Nicola.Musatti@gmail.com>wrote:
Hallo, sorry to insist, but I think this should go in rather sooner than later.
Agreed, but I've got family commitments today, so can't look at it. If Eric is available, perhaps he could take a look. --Beman
Cheers, Nicola
Nicola Musatti wrote:
Nicola Musatti wrote:
Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, and it doesn't include the tests for several libraries.
No, it's much worse than that. I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
Let me know if you need any help with this.
Cheers, Nicola
-- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Nicola Musatti wrote:
Hallo, sorry to insist, but I think this should go in rather sooner than later.
Thanks for the head-up Nicola. Some questions below ...
Nicola Musatti wrote:
Nicola Musatti wrote:
Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago,
What makes you say that? The tests on the release branch have been running successfully.
and it doesn't include the tests for several libraries.
Which ones?
No, it's much worse than that. I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
Let me know if you need any help with this.
How did you come up with this list? It's really up to the authors of those libraries whether to merge to release or not, right? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Nicola Musatti wrote:
I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
The boost::swap utility isn't yet part of the release branch (although it's in the trunk for a few months now). So in the case of utility/swap, it's not just the tests that need to be merged. Eric Niebler wrote:
How did you come up with this list? It's really up to the authors of those libraries whether to merge to release or not, right?
I was thinking so too... In the case of utility/swap I think it's up to Joseph Gauterin in the first place. Anyway, thanks for being alert, Nicola! Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Niels Dekker - mail address until 2008-12-31 wrote:
Nicola Musatti wrote:
I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
The boost::swap utility isn't yet part of the release branch (although it's in the trunk for a few months now). So in the case of utility/swap, it's not just the tests that need to be merged.
I would like boost::swap to be released because I want to start using it, but I don't remember it having a review. Isn't it necessary for a new library to have a formal review? Maybe I just missed it. Thanks, -- Michael Marcin
Michael Marcin wrote:
I would like boost::swap to be released because I want to start using it, but I don't remember it having a review. Isn't it necessary for a new library to have a formal review? Maybe I just missed it.
The boost::swap utility isn't formally reviewed, but it's been discussed here quite extensively. (Just search your Boost-mail on "[swap]" and "[utility/swap]"!) Joseph Gauterin has moved his utility from the sandbox to the trunk 4 months ago, following a request ticket of mine: http://svn.boost.org/trac/boost/ticket/2056 Especially Steven Watanabe and David Abrahams have been very helpful to the development of boost::swap as well. So it's now at http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp Personally I wouldn't mind if the boost::swap utility would be released without a formal review. Because it's just a little utility. Or do you think that there are some aspects of boost::swap that should be discussed beforehand? Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
----- Original Message ----- From: "Niels Dekker - mail address until 2008-12-31" <nd_mail_address_valid_until_2008-12-31@xs4all.nl> To: <boost@lists.boost.org> Sent: Monday, October 20, 2008 11:20 PM Subject: [boost] [utility/swap] The boost::swap utility
Personally I wouldn't mind if the boost::swap utility would be released without a formal review. Because it's just a little utility. Or do you think that there are some aspects of boost::swap that should be discussed beforehand?
Hi, In fact this is already on the trunk, so don't need any review. It is just already accepted implicitly and used by other libraries on the trunk. Just to remind, there was atleast one library that have removed its boost::swap uses when merged to the release branch. Why this little utility was not merged then? There is nothing critical that needs the boost::swap inclusion. No I definitiviely think that we need to *respect* the defined process. If we want to change the process we can discuss this changes directly here, and apply them when adopted. We need just to wait three months for its inclusion. Vicente
on Mon Oct 20 2008, Michael Marcin <mike.marcin-AT-gmail.com> wrote:
Niels Dekker - mail address until 2008-12-31 wrote:
Nicola Musatti wrote:
I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
The boost::swap utility isn't yet part of the release branch (although it's in the trunk for a few months now). So in the case of utility/swap, it's not just the tests that need to be merged.
I would like boost::swap to be released because I want to start using it, but I don't remember it having a review. Isn't it necessary for a new library to have a formal review? Maybe I just missed it.
It's not technically a new library; it's an enhancement to the Boost.Utility library, so it doesn't need a separate review. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Mon Oct 20 2008, David Abrahams <dave-AT-boostpro.com> wrote:
on Mon Oct 20 2008, Michael Marcin <mike.marcin-AT-gmail.com> wrote:
Niels Dekker - mail address until 2008-12-31 wrote:
Nicola Musatti wrote:
I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
The boost::swap utility isn't yet part of the release branch (although it's in the trunk for a few months now). So in the case of utility/swap, it's not just the tests that need to be merged.
I would like boost::swap to be released because I want to start using it, but I don't remember it having a review. Isn't it necessary for a new library to have a formal review? Maybe I just missed it.
It's not technically a new library; it's an enhancement to the Boost.Utility library, so it doesn't need a separate review.
On the other hand, as the utility library author that accepted the patches, it was probably my responsibility to merge it to release. Too late now, I suppose :( -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Oct 20, 2008 at 9:37 PM, David Abrahams <dave@boostpro.com> wrote:
I would like boost::swap to be released because I want to start using it, but I don't remember it having a review. Isn't it necessary for a new library to have a formal review? Maybe I just missed it.
It's not technically a new library; it's an enhancement to the Boost.Utility library, so it doesn't need a separate review.
On the other hand, as the utility library author that accepted the patches, it was probably my responsibility to merge it to release. Too late now, I suppose :(
Cross your fingers, but the 1.37.0 beta should go out tomorrow. If that happens, there will be ten days or so before the release is scheduled to ship. I'd like to use that time to improve the quality of the release. As long as it improves quality and is low risk (as shown by being stable in trunk), I think it would be OK to do the merge once the beta ships. But please don't commit anything to branches/release until then. We need to feel our way carefully; I don't want the beta being more or less on time to be taken as an excuse to flood branches/release with an unmanageable number of late merges. But there isn't much point of doing a beta if we aren't willing to make at least some fixes before final release. Thanks, --Beman
As long as it improves quality and is low risk (as shown by being stable in trunk), I think it would be OK to do the merge once the beta ships. But please don't commit anything to branches/release until then. I think that utility/swap is pretty low risk, as it's been stable on the trunk for a few months now, it's very small and it doesn't yet have any dependencies.
Cross your fingers, but the 1.37.0 beta should go out tomorrow. If that happens, there will be ten days or so before the release is scheduled to ship. I'd like to use that time to improve the quality of the release. Would you be happy for me to merge boost::swap from the trunk to the release branch now that the beta has been released?
Regards, Joe Gauterin.
Eric Niebler <eric <at> boost-consulting.com> writes:
Nicola Musatti wrote:
Hallo, sorry to insist, but I think this should go in rather sooner than later.
Thanks for the head-up Nicola. Some questions below ...
Nicola Musatti wrote:
Nicola Musatti wrote:
Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago,
What makes you say that? The tests on the release branch have been running successfully.
I'm not sure where the difference is between how the official regression tests are run and how local testing is performed. If I run bjam from the boost/status directory in a sandbox checked out from branches/release with a command line as the following: bjam -a --v2 --dump-tests toolset=borland-6.1.0 The tests for the libraries I listed below aren't run.
and it doesn't include the tests for several libraries.
Which ones?
No, it's much worse than that. I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
Let me know if you need any help with this.
How did you come up with this list? It's really up to the authors of those libraries whether to merge to release or not, right?
I started by comparing the test results I get by running process_jam_log/compiler_status on trunk and on branches/release and noticed that the latter was missing a few results. I then compared the corresponding libraries' directories under boost/libs and noticed that a few of them were lacking their respective test subdirectory, while others had other discrepancies. I can't reach my testing environment right now, but if I remember correctly array, crc, functional/hash and rational all lack their test directory, preprocessor is lacking its test/Jamfile.v2 file and utility/swap is completely missing from the release branch. Concerning this last issue I took the liberty of mailing utility/swap's author to remind him about the need of merging. I'm aware that library authors should take care of merging their libraries to the release branch, but some of these libraries are quite old and their authors may not be that active in Boost any more; I'm not even sure they were involved in the test reorganization. Judging from the svn logs the reorganization was actually performed by Rene Rivera. Cheers, Nicola
Nicola Musatti wrote:
What makes you say that? The tests on the release branch have been running successfully.
I'm not sure where the difference is between how the official regression tests are run and how local testing is performed. If I run bjam from the boost/status directory in a sandbox checked out from branches/release with a command line as the following:
bjam -a --v2 --dump-tests toolset=borland-6.1.0
The tests for the libraries I listed below aren't run.
Hmm, just tried: bjam -n -a --dump-tests toolset=borland and the libs you list do have their tests run (which doesn't mean we shouldn't merge status/Jamfile.v2 changes of course, the question is whether to do it now). Also those libs do have their test results showing up in the test matrix. Confused yours, John.
On Mon, Oct 20, 2008 at 5:07 AM, John Maddock <john@johnmaddock.co.uk>wrote:
Nicola Musatti wrote:
What makes you say that? The tests on the release branch have been
running successfully.
I'm not sure where the difference is between how the official regression tests are run and how local testing is performed. If I run bjam from the boost/status directory in a sandbox checked out from branches/release with a command line as the following:
bjam -a --v2 --dump-tests toolset=borland-6.1.0
The tests for the libraries I listed below aren't run.
Hmm, just tried:
bjam -n -a --dump-tests toolset=borland
and the libs you list do have their tests run (which doesn't mean we shouldn't merge status/Jamfile.v2 changes of course, the question is whether to do it now). Also those libs do have their test results showing up in the test matrix.
Confused yours, John.
Me too. In any case, this doesn't seem to be something to hold up the beta for, so unless I hit some other showstopper as I scan unread mail, I'm going to start building the beta today. --Beman
John Maddock wrote:
Nicola Musatti wrote:
What makes you say that? The tests on the release branch have been running successfully.
I'm not sure where the difference is between how the official regression tests are run and how local testing is performed. If I run bjam from the boost/status directory in a sandbox checked out from branches/release with a command line as the following:
bjam -a --v2 --dump-tests toolset=borland-6.1.0
The tests for the libraries I listed below aren't run.
Hmm, just tried:
bjam -n -a --dump-tests toolset=borland
and the libs you list do have their tests run (which doesn't mean we shouldn't merge status/Jamfile.v2 changes of course, the question is whether to do it now). Also those libs do have their test results showing up in the test matrix.
My mistake. I was confused by the fact that the test results for these libraries end up under bin.v2/status and so aren't picked up by the current version of compiler_status.cpp, which I modified a few months ago to cater for the reorganized test directories :-( Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/
CC'ing Rene ... Nicola Musatti wrote:
Eric Niebler <eric <at> boost-consulting.com> writes:
Nicola Musatti wrote:
Hallo, sorry to insist, but I think this should go in rather sooner than later. Thanks for the head-up Nicola. Some questions below ...
Nicola Musatti wrote:
Nicola Musatti wrote:
Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, What makes you say that? The tests on the release branch have been running successfully.
I'm not sure where the difference is between how the official regression tests are run and how local testing is performed. If I run bjam from the boost/status directory in a sandbox checked out from branches/release with a command line as the following:
bjam -a --v2 --dump-tests toolset=borland-6.1.0
The tests for the libraries I listed below aren't run.
But from the release test results here: http://beta.boost.org/development/tests/release/developer/summary.html it appears these tests are in fact getting run.
and it doesn't include the tests for several libraries. Which ones?
No, it's much worse than that. I suspect that several libraries' test directories need to be merged to release: - array - crc - functional - integer (?) - preprocessor (?) - rational - utility/swap
Let me know if you need any help with this. How did you come up with this list? It's really up to the authors of those libraries whether to merge to release or not, right?
I started by comparing the test results I get by running process_jam_log/compiler_status on trunk and on branches/release and noticed that the latter was missing a few results. I then compared the corresponding libraries' directories under boost/libs and noticed that a few of them were lacking their respective test subdirectory, while others had other discrepancies. I can't reach my testing environment right now, but if I remember correctly array, crc, functional/hash and rational all lack their test directory, preprocessor is lacking its test/Jamfile.v2 file and utility/swap is completely missing from the release branch. Concerning this last issue I took the liberty of mailing utility/swap's author to remind him about the need of merging.
But looking at the status/Jamfile.v2 on the release branch, none of these are issues. These libraries don't follow the normal boost convention of having a test directory with a Jamfile.v2 in it; rather, the tests are invoked directly from the status/Jamfile.v2. And utility/swap which isn't part of 1.37 IIUC. Everything looks copacetic to me.
I'm aware that library authors should take care of merging their libraries to the release branch, but some of these libraries are quite old and their authors may not be that active in Boost any more; I'm not even sure they were involved in the test reorganization. Judging from the svn logs the reorganization was actually performed by Rene Rivera.
It would certainly be good to sync up trunk and release after 1.37 is out, to avoid this confusion and to make it easier to merge changes to status/Jamfile.v2. In fact, I wonder why this wasn't done for 1.37 (Rene?) but it's too late now. -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (9)
-
Beman Dawes -
David Abrahams -
Eric Niebler -
John Maddock -
Joseph Gauterin -
Michael Marcin -
Nicola Musatti -
Niels Dekker - mail address until 2008-12-31 -
vicente.botet