On Thu, Mar 28, 2013 at 12:36 AM, Ben Pope wrote:

On 28/03/13 12:03, Steven Watanabe wrote:

...

AMDG

The list of required toolsets in explicit-failures-markup.xml is out-dated. Therefore, if no one objects, I propose setting it to the following:

msvc-10.0, msvc-11.0, gcc-4.6, gcc-4.7, clang-darwin-11, clang-darwin-4.2.1, clang-linux-3.1, clang-linux-3.2, gcc-mingw-4.7, gcc-mingw-4.6

I'm guessing that would look like:

Linux: gcc-4.6, gcc-4.7, clang-linux-3.1, clang-linux-3.2, OSX: clang-darwin-11, clang-darwin-4.2.1 Windows: msvc-10.0, msvc-11.0, gcc-4.6, gcc-4.7 cc-mingw-4.7, gcc-mingw-4.6

Some supported toolset rules that have been mostly implicit in the past: a) the toolset must appear in the release test results and trunk only toolset can't be included, b) they must have demonstrated reliable and consistent testing cycles, and c) only release version of toolsets qualify. Usually if they violate (b) they tend to get removed from release testing (i.e. someone asks them to stop testing them or test more frequently). So I would modify the list as: Linux: gcc-4.6, gcc-4.7, clang-linux-3.1 OSX: clang-darwin-11, clang-darwin-4.2.1, darwin-4.2.1 Windows: gcc-mingw-4.7, gcc-mingw-4.6 msvc-8.0 Yes, msvc-8.0 is currently the *only* msvc compiler consistently tested on the release branch! So if we want the modern version of msvc compilers someone needs to step up and volunteer to support *release* testing on the msvc modern compilers!!! -- -- -- 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

On Mar 28, 2013, at 5:53 PM, Michael Marcin wrote:

Rene Rivera wrote:

...

Linux: gcc-4.6, gcc-4.7, clang-linux-3.1 OSX: clang-darwin-11, clang-darwin-4.2.1, darwin-4.2.1 Windows: gcc-mingw-4.7, gcc-mingw-4.6 msvc-8.0

Yes, msvc-8.0 is currently the *only* msvc compiler consistently tested on the release branch! So if we want the modern version of msvc compilers someone needs to step up and volunteer to support *release* testing on the msvc modern compilers!!!

Is there a guide for setting up running these tests?

Sure. http://www.boost.org/development/running_regression_tests.html Btw, the names of the OSX configurations are kind of confusing: darwin-4.2.1 - the last release of gcc from Apple (gcc-4.2.1) clang-darwin-4.2.1 - the current release of clang from Apple, using the libstdc++ from gcc 4.2.1 clang-darwin-11 - the current release of clang from Apple, with -std=c++11 -stdlib=libc++ -- Marshall Marshall Clow Idio Software mailto:mclow.lists@gmail.com A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

Rene Rivera wrote:

On Thu, Mar 28, 2013 at 9:50 PM, Marshall Clow wrote:

...

On Mar 28, 2013, at 5:53 PM, Michael Marcin wrote:

...

Rene Rivera wrote:

...

Linux: gcc-4.6, gcc-4.7, clang-linux-3.1 OSX: clang-darwin-11, clang-darwin-4.2.1, darwin-4.2.1 Windows: gcc-mingw-4.7, gcc-mingw-4.6 msvc-8.0

Yes, msvc-8.0 is currently the *only* msvc compiler consistently tested

...

the release branch! So if we want the modern version of msvc compilers someone needs to step up and volunteer to support *release* testing on

on the

...

msvc modern compilers!!!

Is there a guide for setting up running these tests?

Sure. http://www.boost.org/development/running_regression_tests.html

FYI.. The first step before running release testing is to run *trunk* testing. After we see a few cycles of that without problems you can ask to move to release testing.

What's the toolset id for msvc 11 update 1? Is there a way to list toolset options or a documentation page with them?

Steven Watanabe wrote:

AMDG

On 03/28/2013 08:48 PM, Michael Marcin wrote:

...

What's the toolset id for msvc 11 update 1?

msvc-11.0

There's no difference between vc++2012 rtm and update 1?

AMDG On 03/29/2013 08:31 PM, Michael Marcin wrote:

There are occasional assertions and crashes that require manual intervention.

Is this expected?

It should be killed automatically after 5 minutes unless you specify a shorter time out. See also http://www.sevenforums.com/tutorials/4550-problem-reports-solutions-change-p... In Christ, Steven Watanabe

AMDG On 03/29/2013 09:23 AM, Thales wrote:

I am going to try to run a regression test for VS 2012. :-)

Is this what I do?

1> Create a new directory. I'll give it the name BoostTest

2> Then, copy "run.py" to that directory.

3> Then run the following on the command line: python run.py --runner=John_Alway_VS2012 --toolset=msvc-11.0

It should be --toolsets=msvc-11.0, but otherwise this should be okay.

Would that start the testing? "John_Alway_VS2012" is just a made up id. I get the impression results are reported back automatically to Boost?

Yep. run.py should handle everything.

I'm sure I'm missing something somewhere, but this is what I have so far.

Why? We try to make this as simple as possible.

I guess that tests the trunk?

I did run bjam for one of the libraries (chrono), and it seemed to work, although all of the information was just output to the screen and not saved.

In Christ, Steven Watanabe

Okay.   I guess I'll try N=2 for now.   I'm not sure how taxing this will be on the system. Thanks! ...John ________________________________ From: Steven Watanabe To: boost@lists.boost.org Sent: Friday, March 29, 2013 11:40 AM Subject: Re: [boost] required toolsets AMDG On 03/29/2013 09:23 AM, Thales wrote:

I am going to try to run a regression test for VS 2012.  :-)

Is this what I do?

1> Create a new directory.  I'll give it the name BoostTest

2> Then, copy "run.py" to that directory.

3> Then run the following on the command line: python run.py --runner=John_Alway_VS2012    --toolset=msvc-11.0

I should add that you probably want --bjam-options=-jN where N is the number of jobs to run in parallel. In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

There appears to be an error: Windows Error: [Error 3]   The system cannot find the path specified: 'C:\\BoostTest\\results\\boost/bin.v2/libs/any/test/any_test.test/*.*' ________________________________ From: Steven Watanabe To: boost@lists.boost.org Sent: Friday, March 29, 2013 11:40 AM Subject: Re: [boost] required toolsets AMDG On 03/29/2013 09:23 AM, Thales wrote:

I am going to try to run a regression test for VS 2012.  :-)

Is this what I do?

1> Create a new directory.  I'll give it the name BoostTest

2> Then, copy "run.py" to that directory.

3> Then run the following on the command line: python run.py --runner=John_Alway_VS2012    --toolset=msvc-11.0

I should add that you probably want --bjam-options=-jN where N is the number of jobs to run in parallel. In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Steven, I've sent out two messages with the log file attached, and neither one seems to have made it. ...John ________________________________ From: Steven Watanabe To: boost@lists.boost.org Sent: Friday, March 29, 2013 8:55 PM Subject: Re: [boost] required toolsets AMDG On 03/29/2013 11:53 AM, Thales wrote:

There appears to be an error:

Windows Error: [Error 3]  The system cannot find the path specified: 'C:\\BoostTest\\results\\boost/bin.v2/libs/any/test/any_test.test/*.*'

What does results/bjam.log say? In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

...

I've sent out two messages with the log file attached, and neither one seems to have made it.

Is it too big for this list? Can you compress it and send it to me off-list?

They're sitting in the moderator queue because they're too big - can you send direct to Steven as suggested and I'll reject the posts to the list - some folks read the list on mobile devices that don't have the bandwidth for large downloads... Many thanks, John.

AMDG On 03/30/2013 09:45 AM, John Maddock wrote:

...

...

I've sent out two messages with the log file attached, and neither one seems to have made it.

Is it too big for this list? Can you compress it and send it to me off-list?

They're sitting in the moderator queue because they're too big - can you send direct to Steven as suggested and I'll reject the posts to the list - some folks read the list on mobile devices that don't have the bandwidth for large downloads...

I've received it. In Christ, Steven Watanabe

28.03.2013 19:20, Rene Rivera пишет:

Yes, msvc-8.0 is currently the *only* msvc compiler consistently tested on the release branch! So if we want the modern version of msvc compilers someone needs to step up and volunteer to support *release* testing on the msvc modern compilers!!! I'll try to setup the tests for the vc-9 (msvc-2008), 10 (msvc-2010) and 11 (msvc-2012) for both trunk and release branches to be run every weekend. I did it several months ago but the server has gone down.

-- Best regards, Sergey Cheban

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Sergey Cheban Sent: Friday, April 12, 2013 10:28 AM To: boost@lists.boost.org Subject: Re: [boost] required toolsets

On 29.03.2013 10:49, Sergey Cheban wrote:

...

28.03.2013 19:20, Rene Rivera пишет:

...

Yes, msvc-8.0 is currently the *only* msvc compiler consistently tested on the release branch! So if we want the modern version of msvc compilers someone needs to step up and volunteer to support *release* testing on the msvc modern compilers!!! I'll try to setup the tests for the vc-9 (msvc-2008), 10 (msvc-2010) and 11 (msvc-2012) for both trunk and release branches to be run every weekend. I did it several months ago but the server has gone down. When trying to run the boost regression tests, I've got the following in the bjam.log:

============== failed to write output file 'C:\Users\BoostTest\Release\results\boost\bin.v2\libs\multiprecision\test\sf_concept_check_elliptic_cpp _dec_float_no_et.test\msvc-10.0\debug\address-model-64\debug-symbols-off\link-static\runtime-link- static\sf_concept_check_elliptic_cpp_dec_float_no_et.obj.rsp'! =============

The length of the file name is 260 characters and it is over the limits of the testing environment (i.e. Windows server 2012). Is it possible to make this path shorter without modifying the "C:\Users\BoostTest\Release" prefix?

I think you need to add the --hash option for b2/bjam to create smaller file/folder names. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

Le 12/04/13 16:39, Steven Watanabe a écrit :

AMDG

On 04/12/2013 03:45 AM, Paul A. Bristow wrote:

...

...

============== failed to write output file 'C:\Users\BoostTest\Release\results\boost\bin.v2\libs\multiprecision\test\sf_concept_check_elliptic_cpp _dec_float_no_et.test\msvc-10.0\debug\address-model-64\debug-symbols-off\link-static\runtime-link- static\sf_concept_check_elliptic_cpp_dec_float_no_et.obj.rsp'! =============

The length of the file name is 260 characters and it is over the limits of the testing environment (i.e. Windows server 2012). Is it possible to make this path shorter without modifying the "C:\Users\BoostTest\Release" prefix? I think you need to add the --hash option for b2/bjam to create smaller file/folder names.

--abbreviate-paths is better as it leaves the result somewhat human readable, although it doesn't get as much compression. Also, the name of the test is a bit long. It really should be shortened.

Let analyze how the name could be shortened C:\Users\BoostTest\Release\results\boost\bin.v2\libs\multiprecision\test\sf_concept_check_elliptic_cpp_dec_float_no_et.test\msvc-10.0\debug\address-model-64\debug-symbols-off\link-static\runtime-link-static\sf_concept_check_elliptic_cpp_dec_float_no_et.obj.rsp *Where the build is stored* (49) : C:\Users\BoostTest\Release\results\boost\bin.v2 -> The user can choose a shorter path ( a big gain) *The lib* (5+14+6=25): libs\multiprecision\test\ Nothing to do here except rename the library name :( The test specific name (46): sf_concept_check_elliptic_cpp_dec_float_no_et. A little bit long and it appear twice ->The author could choose a shorter name but this will reduce not too much the global length. The author can choose names with less than 31 characters (-15ch) *The extension* (5) .test -> Couldn't the suffix be shorten .t (-3) The toolset (10) \msvc-10.0 ->Nothing to (already taken in account by --abbreviate-paths) The location depending on the variants (74) \debug\address-model-64\debug-symbols-off\link-static\runtime-link-static\ . (already taken in account by --abbreviate-paths) The name of the resources: () sf_concept_check_elliptic_cpp_dec_float_no_et.obj.rsp -> Couldn't an option name all the files at these level just TEST.suffix? In this particular case we move from 46 to 4. Resuming * the user could reduce of 40 characters * the boost build could yet reduce of 45 characters easily. * --abbreviate-paths makes already a considerable reduction * the author reduce of 15 characters and of 30 if the name is duplicated. As you can see the reduction related to the test case name is the less significant, so I would suggest to take in priority the two others. I have not used --hash so I don't know id this is the final solution. Best, Vicente

On 28/03/13 23:20, Rene Rivera wrote:

Some supported toolset rules that have been mostly implicit in the past: a) the toolset must appear in the release test results and trunk only toolset can't be included, b) they must have demonstrated reliable and consistent testing cycles, and c) only release version of toolsets qualify. Usually if they violate (b) they tend to get removed from release testing (i.e. someone asks them to stop testing them or test more frequently). So I would modify the list as:

Linux: gcc-4.6, gcc-4.7, clang-linux-3.1

I promise to keep testing with clang-3.2 until clang-3.3 is released. My runner is "BP x86_64 C++11". Ben