Attn: users of minimal.hpp and boost/test/included headers
Hi, Those of you who use minmial.hpp have to add boost/test/minimal in requirements section of Jamfile. Those who are using included variant of the UTF should add boost/test/included. This is nessesary to enable async exceptions for msvc toolset. Otherwise some of the Boost.Test functionality may not work as expected, especially with msvc 8.0. Gennadiy
Gennadiy Rozental wrote:
Hi,
Those of you who use minmial.hpp have to add boost/test/minimal in requirements section of Jamfile. Those who are using included variant of the UTF should add boost/test/included.
This is nessesary to enable async exceptions for msvc toolset. Otherwise some of the Boost.Test functionality may not work as expected, especially with msvc 8.0.
IIUC, you are proposing a breaking change. How many libraries are affected? When do you propose to make this change? After 1.35.0? Remember that tomorrow is the date we are supposed to start looking at libraries to see what is ready for 1.35.0. Do you remember that I asked you not to make any Boost.Test changes until after we figure out how to prevent your changes from breaking other people's libraries? --Beman
"Beman Dawes" <bdawes@acm.org> wrote in message news:4717DC3A.2050700@acm.org...
Gennadiy Rozental wrote:
Hi,
Those of you who use minmial.hpp have to add boost/test/minimal in requirements section of Jamfile. Those who are using included variant of the UTF should add boost/test/included.
This is nessesary to enable async exceptions for msvc toolset. Otherwise some of the Boost.Test functionality may not work as expected, especially with msvc 8.0.
IIUC, you are proposing a breaking change.
I am not proposing any changes. This is how it was for a long while.
How many libraries are affected?
I don't really know. I just notices it in SmokeTest result page. I had a discussion with Volodya yesterday and he says BB can't figure it out by itself and this is what he proposed. I obviously would prefer BB to deduce it somehow automatically, since it analyze header dependencies anyway. Gennadiy
Gennadiy Rozental wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:4717DC3A.2050700@acm.org...
Gennadiy Rozental wrote:
Hi,
Those of you who use minmial.hpp have to add boost/test/minimal in requirements section of Jamfile. Those who are using included variant of the UTF should add boost/test/included.
This is nessesary to enable async exceptions for msvc toolset. Otherwise some of the Boost.Test functionality may not work as expected, especially with msvc 8.0. IIUC, you are proposing a breaking change.
I am not proposing any changes. This is how it was for a long while.
How many libraries are affected?
I don't really know. I just notices it in SmokeTest result page.
Looking at those tests for Win32 now (rev 40170), there are 16 failures, which is where we were this morning. So it doesn't look like anything new is broken. But, please, be very conservative with the trunk while we are in the middle of getting this release ready. --Beman PS: One good thing that has come out of this is that I've realized that if I commit each smoke test to a repository, I can go back later and see exactly what revision causes a breakage (and by correlating the revision number with the log, who did the commit). I'll give this a try for a few days to see if it works. If it does, maybe it can go in the boost repository so anyone can look at it.
on Thu Oct 18 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Gennadiy Rozental wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:4717DC3A.2050700@acm.org...
Gennadiy Rozental wrote:
Hi,
Those of you who use minmial.hpp have to add boost/test/minimal in requirements section of Jamfile. Those who are using included variant of the UTF should add boost/test/included.
This is nessesary to enable async exceptions for msvc toolset. Otherwise some of the Boost.Test functionality may not work as expected, especially with msvc 8.0. IIUC, you are proposing a breaking change.
I am not proposing any changes. This is how it was for a long while.
How many libraries are affected?
I don't really know. I just notices it in SmokeTest result page.
Looking at those tests for Win32 now (rev 40170), there are 16 failures, which is where we were this morning. So it doesn't look like anything new is broken.
But, please, be very conservative with the trunk while we are in the middle of getting this release ready.
Really, he's not making any changes; he's just announcing that he learned library authors who are using Boost.Test need to take some special actions that most people didn't know about before.
--Beman
PS: One good thing that has come out of this is that I've realized that if I commit each smoke test to a repository, I can go back later and see exactly what revision causes a breakage (and by correlating the revision number with the log, who did the commit). I'll give this a try for a few days to see if it works. If it does, maybe it can go in the boost repository so anyone can look at it.
How is that different from what's discussed in http://lists.boost.org/Archives/boost/2007/08/125906.php ? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Thu Oct 18 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Gennadiy Rozental wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:4717DC3A.2050700@acm.org...
Gennadiy Rozental wrote:
Hi,
Those of you who use minmial.hpp have to add boost/test/minimal in requirements section of Jamfile. Those who are using included variant of the UTF should add boost/test/included.
This is nessesary to enable async exceptions for msvc toolset. Otherwise some of the Boost.Test functionality may not work as expected, especially with msvc 8.0. IIUC, you are proposing a breaking change. I am not proposing any changes. This is how it was for a long while.
How many libraries are affected? I don't really know. I just notices it in SmokeTest result page. Looking at those tests for Win32 now (rev 40170), there are 16 failures, which is where we were this morning. So it doesn't look like anything new is broken.
But, please, be very conservative with the trunk while we are in the middle of getting this release ready.
Really, he's not making any changes; he's just announcing that he learned library authors who are using Boost.Test need to take some special actions that most people didn't know about before.
--Beman
PS: One good thing that has come out of this is that I've realized that if I commit each smoke test to a repository, I can go back later and see exactly what revision causes a breakage (and by correlating the revision number with the log, who did the commit). I'll give this a try for a few days to see if it works. If it does, maybe it can go in the boost repository so anyone can look at it.
How is that different from what's discussed in http://lists.boost.org/Archives/boost/2007/08/125906.php
Putting test results in a database is a great long-term solution that I hope happens someday. But I'm not holding my breath. Putting test results in a local repository for a single smoke test series is something that I was able to implement this morning in perhaps 15 minutes and is working now. So it helps with this release, even though it is a band-aid. --Beman
on Fri Oct 19 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
PS: One good thing that has come out of this is that I've realized that if I commit each smoke test to a repository, I can go back later and see exactly what revision causes a breakage (and by correlating the revision number with the log, who did the commit). I'll give this a try for a few days to see if it works. If it does, maybe it can go in the boost repository so ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ anyone can look at it.
How is that different from what's discussed in http://lists.boost.org/Archives/boost/2007/08/125906.php
Putting test results in a database is a great long-term solution that I hope happens someday. But I'm not holding my breath.
Putting test results in a local repository for a single smoke test series is something that I was able to implement this morning in perhaps 15 minutes and is working now. So it helps with this release, even though it is a band-aid.
I think you misunderstood my question. That thread discusses the idea of putting test results into the boost repo and points out several disadvantages to doing so. Is there any reason to think those disadvantages wouldn't apply in this case? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Fri Oct 19 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
PS: One good thing that has come out of this is that I've realized that if I commit each smoke test to a repository, I can go back later and see exactly what revision causes a breakage (and by correlating the revision number with the log, who did the commit). I'll give this a try for a few days to see if it works. If it does, maybe it can go in the boost repository so ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ anyone can look at it. How is that different from what's discussed in http://lists.boost.org/Archives/boost/2007/08/125906.php Putting test results in a database is a great long-term solution that I hope happens someday. But I'm not holding my breath.
Putting test results in a local repository for a single smoke test series is something that I was able to implement this morning in perhaps 15 minutes and is working now. So it helps with this release, even though it is a band-aid.
I think you misunderstood my question. That thread discusses the idea of putting test results into the boost repo and points out several disadvantages to doing so. Is there any reason to think those disadvantages wouldn't apply in this case?
I'm concern they *do* apply. That's why I'm using a local repository rather than svn.boost.org/svn. --Beman
Gennadiy Rozental wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:4717DC3A.2050700@acm.org...
Gennadiy Rozental wrote:
Hi,
Those of you who use minmial.hpp have to add boost/test/minimal in requirements section of Jamfile. Those who are using included variant of the UTF should add boost/test/included.
To be exact, /boost/test//minimal and /boost/test//included
This is nessesary to enable async exceptions for msvc toolset. Otherwise some of the Boost.Test functionality may not work as expected, especially with msvc 8.0.
IIUC, you are proposing a breaking change.
I am not proposing any changes. This is how it was for a long while.
How many libraries are affected?
I don't really know. I just notices it in SmokeTest result page.
I had a discussion with Volodya yesterday and he says BB can't figure it out by itself and this is what he proposed.
I obviously would prefer BB to deduce it somehow automatically, since it analyze header dependencies anyway.
To clarify, by "it" Gennadiy means that he wanted that Boost.Build detect that a source file includes Boost.Test headers, and automatically adds certain compiler options. And this is not a feature that appears as common as to warrant a special support, IMO. - Volodya
Vladimir Prus <ghost <at> cs.msu.su> writes:
To be exact, /boost/test//minimal and /boost/test//included
I must say this double / requirement is quite ummm.. obscure.
I obviously would prefer BB to deduce it somehow automatically, since it analyze header dependencies anyway.
To clarify, by "it" Gennadiy means that he wanted that Boost.Build detect that a source file includes Boost.Test headers, and automatically adds certain compiler options. And this is not a feature that appears as common as to warrant a special support, IMO.
Actually it might be quite generic problem. Depending on particular header in use you may want turn on/off optimization, threading, define some macro and add addditional compiler option (like in my case). On the other hand explicit dependency maybe usefull in a long term, so I guess it's ok. Gennadiy
Gennadiy Rozental wrote:
On the other hand explicit dependency maybe usefull in a long term, so I guess it's ok.
And it's not like a BB feature is going to help non-BB users of the library. So you'd have to implement something outside of BB anyway. Most likely docs. -- -- 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
participants (5)
-
Beman Dawes -
David Abrahams -
Gennadiy Rozental -
Rene Rivera -
Vladimir Prus