[winrt support] Adding support for Windows 8 store/phone to Boost libraries
Hi, I work for Microsoft and we’ve been taking a look at making a some of the libraries in Boost work in the Windows 8 store and phone 8 runtime environment (WinRT). The main issue is use of Win32 desktop APIs that are banned in WinRT. The fixes generally involve updating to a newer non-banned version, like CreateEvent to CreateEventEx, or replace areas that call banned APIs using ifdef macro techniques. Similar to what already exists in some places of Boost when targeting different platforms or operating system versions. Files which do not use any banned APIs are largely unaffected. So far we’ve made the thread, chrono, system, and date_time libraries work in WinRT. To facilitate building and testing, changes are also required to the build and test libraries. Listed at the end of this message is a summary of the major changes made. I’m unfamiliar with the process for contributing back to Boost and would like to know what is the best way to work, to contributing back these changes to each of the individual libraries? I see the documentation for working with the git submodules (https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq). Right now the changes for each library are in a forked repository on a new branch called ‘winrt’ from the ‘develop’ branch. For example the changes we've made for the chrono library can be located here: https://github.com/MSOpenTech/chrono/tree/winrt. Is the best way to proceed, or should I to just initiate a pull request to the develop branch on each of the individual libraries? Thanks, Steve Boost Build To support deciding which Windows API to target I added a new feature <windows-api> with values desktop, store, and phone. When utilizing the Visual Studio 2012 on Windows 8 or later the store and phone options are available, otherwise desktop is the default. Most of the changes in msvc.jam are to deal with selecting the correct vcvars setup script since with phone it is in a different location. I also added ARM support to the msvc toolset. For libraries which support the new Windows Runtime they now produce both the desktop and store binaries by default. This is done by calling the supported-windows-api rule I added in toolset.msvc which is called in the default-build section of each library’s Jamfile to indicate if targeting WinRT is supported. When building for the Windows 8 store or phone a new macro is now defined BOOST_WINAPI_FAMILY, set with the same value as WINAPI_FAMILY. This is then used in the individual Boost libraries to detect if targeting the new Windows Runtime and avoid certain banned APIs. To handle running tests against WinRT in an automated fashion that integrates well into the Boost workflow of running tests as part of the build, if windows-api is set to store, the test and all its binary dependencies need to have the APPCONTAINER requirement stripped. This then allows execution outside of the sandboxed Windows store environment. To do this all dependent dlls are copied into the tests executable’s folder, if using <link>shared. This is necessary to avoid modifying the APPCONTAINER flag on the actual product binaries. Just let me know if this needs more explanation, I’ll be glad to go into more detail if necessary. With this change the tests for Windows store run just like the existing Windows tests. I also added a new feature to control whether or not test binaries are actually executed, disable-test-execution. This is used to avoid running the ARM tests when building since Visual Studio 2012 doesn’t install on ARM devices. All these changes are in testing.msvc. Chrono The GetProcessTimes and GetThreadTimes functions doesn’t exist for WinRT and there are no replacements so the thread_clock and process user, system, and cpu clock features are disabled. Only process_real_cpu_clock is supported. Thread For the thread library most of the changes are around the fact that there is no way to directly create a thread in WinRT. To work around this I implemented the boost::thread class itself on top of std::thread. This actually leads to pretty clean code, much cleaner than directly targeting the WRL thread pool like in the C runtime. Other changes include moving from TLS to FLS and basic banned API replacements like WaitForSingleObjectEx for WaitForSingleObject. In general where it makes sense updates were made to utilize new APIs on platforms when available. Test For the Boost test library I added a new macro for turning on/off debugging support (BOOST_TEST_HAS_DEBUG_SUPPORT). WinRT doesn’t support creating processes so attaching a debugger to execution like this is disabled. There also are no APIs for accessing registry keys, so this feature has been disabled as well. -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On April 25, 2014 1:02:09 PM EDT, stgates
Hi,
I work for Microsoft and we’ve been taking a look at making a some of the libraries in Boost work in the Windows 8 store and phone 8 runtime environment (WinRT).
Very nice.
I’m unfamiliar with the process for contributing back to Boost and would like to know what is the best way to work, to contributing back these changes to each of the individual libraries? I see the documentation for working with the git submodules (https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq). Right now the changes for each library are in a forked repository on a new branch called ‘winrt’ from the ‘develop’ branch. For example the changes we've made for the chrono library can be located here: https://github.com/MSOpenTech/chrono/tree/winrt.
Is the best way to proceed, or should I to just initiate a pull request to the develop branch on each of the individual libraries?
Each library has its own maintainer(s), so changes must be via pull requests for the separate libraries. If changes have to be coordinated between more than one library, then you definitely need to post to this list, too. ___ Rob (Sent from my portable computation engine)
On 25 Apr 2014 at 10:02, stgates wrote:
I work for Microsoft and we´ve been taking a look at making a some of the libraries in Boost work in the Windows 8 store and phone 8 runtime environment (WinRT).
Having recently been dismissed from a similar multinational where publicly contributing to open source except through your wife's name is career damaging/destroying, I firstly want to thank you personally for taking the time, effort and risk in the above.
The main issue is use of Win32 desktop APIs that are banned in WinRT. The fixes generally involve updating to a newer non-banned version, like CreateEvent to CreateEventEx, or replace areas that call banned APIs using ifdef macro techniques.
As a general rule, open source maintainers really hate #ifdef far more than they are hated in big corporations. A patch containing any #ifdef's not absolutely and uncategorically necessary would be rightly rejected. By unnecessary, I mean, for example, if you added a separate CreateEventEx implementation just for WinRT when clearly the Win32 implementation could be modified to work on both Win32 and WinRT.
Similar to what already exists in some places of Boost when targeting different platforms or operating system versions. Files which do not use any banned APIs are largely unaffected. So far we´ve made the thread, chrono, system, and date_time libraries work in WinRT. To facilitate building and testing, changes are also required to the build and test libraries. Listed at the end of this message is a summary of the major changes made.
You are not filling me with optimism unfortunately (though I haven't examined your source code, so I could be wrong). WinRT is essentially a reduced subset of Win32, just as WinCE was. It is not a separate target and should not be treated as one. Rather, it's a target dialect, much as FreeBSD and Linux are dialects of Unix.
I´m unfamiliar with the process for contributing back to Boost and would like to know what is the best way to work, to contributing back these changes to each of the individual libraries?
It's maintainer led, so basically one person controls each library delegating to others where appropriate, and it's up to their personal whims. Be aware some maintainers will refuse to compile code on Windows as it "isn't POSIX", so be prepared to do much extra donkey work for Windows for some libraries. Some maintainers take three to six months to get round to replying to you, so also be aware of that. You'll get far further and quicker if you can demonstrate that your changes cause no regressions and add very little new complexity, and it helps to include soak tests. Also, you'll need to write a ton of documentation for anything added. See below for an idea to generate some goodwill.
To support deciding which Windows API to target I added a new feature <windows-api> with values desktop, store, and phone. When utilizing the Visual Studio 2012 on Windows 8 or later the store and phone options are available, otherwise desktop is the default. Most of the changes in msvc.jam are to deal with selecting the correct vcvars setup script since with phone it is in a different location. I also added ARM support to the msvc toolset. For libraries which support the new Windows Runtime they now produce both the desktop and store binaries by default. This is done by calling the supported-windows-api rule I added in toolset.msvc which is called in the default-build section of each library´s Jamfile to indicate if targeting WinRT is supported. When building for the Windows 8 store or phone a new macro is now defined BOOST_WINAPI_FAMILY, set with the same value as WINAPI_FAMILY. This is then used in the individual Boost libraries to detect if targeting the new Windows Runtime and avoid certain banned APIs.
Sounds excellent. Boost might approach Android-level functionality on WinRT soon if you keep at it like this. FYI, Boost only has a partially functioning port on Android, basically the bits people needed. In particular, Boost isn't regularly regression tested on Android, so stuff does break more frequently than is helpful. If you can supply a feed of regular Boost regression testing for WinRT (especially if on ARM as well), I think you'd get lots of very positive goodwill in return here. This basically involves setting up a local machine testing per commit which sends the XML with the results to one of Boost's servers. If this is an option, do say so and I'm sure the relevant people will chime in. Regarding the considerable work beyond mere coding required to get a platform support patchset into Boost, a lot of it is work which won't have an approved business case in a company like Microsoft i.e. you aren't supposed to work on it during office hours. Also, if it was anything like my former employer, the business processes aren't well adapted to work items stretching over six months where the work is done in unpredictable bursts (i.e. when everyone involved has a shared window of free time) which will throw you off your "proper" work. After my recent multinational corporate adventure I have since returned to employment in open source, and while nothing like as well paid as working for the majors, I have to admit the money differential isn't currently bothering me in the slightest because everyone I work with "gets it". They also read their email incidentally, something I've found is too uncommon in corporations where if it ain't in the top two lines and has the right subject, forget about it. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Hi Niall,
Having recently been dismissed from a similar multinational where publicly contributing to open source except through your wife's name is career damaging/destroying, I firstly want to thank you personally for taking the time, effort and risk in the above.
Thanks. To be clear here Microsoft is aware of this work, and is evolving. It isn't something being done only in my spare time. Microsoft is getting much better about open source. For example I also work on a C++ open source project, the C++ Rest SDK https://casablanca.codeplex.com/ .
By unnecessary, I mean, for example, if you added a separate CreateEventEx implementation just for WinRT when clearly the Win32 implementation could be modified to work on both Win32 and WinRT.
Yes I completely agree and this is exactly what I did :). For example instead of just using CreateEventEx for only WinRT I instead made changes to use CreateEventEx to always be used so it works in Win32 and WinRT.
You'll get far further and quicker if you can demonstrate that your changes cause no regressions and add very little new complexity, and it helps to include soak tests. Also, you'll need to write a ton of documentation for anything added. See below for an idea to generate some goodwill.
I agree, I'm running all the tests to make sure we don't introduce any regressions. I assume a requirement by any library maintainer would be to not regress or break tests.
If you can supply a feed of regular Boost regression testing for WinRT (especially if on ARM as well), I think you'd get lots of very positive goodwill in return here. This basically involves setting up a local machine testing per commit which sends the XML with the results to one of Boost's servers. If this is an option, do say so and I'm sure the relevant people will chime in.
Ok this is something I will think about exploring. Thanks for the tips, Steve -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Mon, Apr 28, 2014 at 11:14 AM, stgates
Thanks. To be clear here Microsoft is aware of this work, and is evolving. It isn't something being done only in my spare time. Microsoft is getting much better about open source.
I'm glad to hear it. I left Microsoft for Intel just recently (February), and my experience at MS was very different with regards to OSS contributions. When I was contributing to Boost (Smart_Ptr) in my spare time at that, it involved a lengthy process for LCA approval. That said, I believe the rules were always different for MS Open Tech, than they were for the rest of us. :-) Glen
On 28 Apr 2014 at 11:14, stgates wrote:
Having recently been dismissed from a similar multinational where publicly contributing to open source except through your wife's name is career damaging/destroying, I firstly want to thank you personally for taking the time, effort and risk in the above.
Thanks. To be clear here Microsoft is aware of this work, and is evolving. It isn't something being done only in my spare time. Microsoft is getting much better about open source. For example I also work on a C++ open source project, the C++ Rest SDK https://casablanca.codeplex.com/ .
That's Artur's thing isn't it? If you work with him, do say hi to him for me. Ale too, he was cool. Separately, when I was interviewing at Microsoft you had just hired Gabriel dos Reis who is very well known in open source. As other posters have mentioned, your experience in a large org as someone known in open source can vary widely - you may attract your own personal hate group within the company, or you may actually get promoted. You can probably guess which I got, but ah well.
By unnecessary, I mean, for example, if you added a separate CreateEventEx implementation just for WinRT when clearly the Win32 implementation could be modified to work on both Win32 and WinRT.
Yes I completely agree and this is exactly what I did :). For example instead of just using CreateEventEx for only WinRT I instead made changes to use CreateEventEx to always be used so it works in Win32 and WinRT.
Excellent. Your patch looks good then. It'll just be everything else to get past: politics, inertia, not-a-real-problem-ness, etc
You'll get far further and quicker if you can demonstrate that your changes cause no regressions and add very little new complexity, and it helps to include soak tests. Also, you'll need to write a ton of documentation for anything added. See below for an idea to generate some goodwill.
I agree, I'm running all the tests to make sure we don't introduce any regressions. I assume a requirement by any library maintainer would be to not regress or break tests.
Unless there is a very good reason e.g. the old tests were actually hiding a problem, then yes.
If you can supply a feed of regular Boost regression testing for WinRT (especially if on ARM as well), I think you'd get lots of very positive goodwill in return here. This basically involves setting up a local machine testing per commit which sends the XML with the results to one of Boost's servers. If this is an option, do say so and I'm sure the relevant people will chime in.
Ok this is something I will think about exploring.
Thanks for the tips,
No problem. I've been where you're now at, and you have my every support. I must admit I failed to release a single line of open source during my entire time with my previous employer, despite writing thousands of lines of code which were intended by my management to be so released. I certainly didn't get any lines of code into any actual open source. BTW, I'll shortly be coming to this list with a new sync object for Boost.Thread called a "permit object" which wraps the failed POSIX pthreads permit object proposal for C11 which solves some of the problems of using condition variables directly. It looks a bit like half of a Win32 event object, but has stronger guarantees. Anyway it'll need to be reviewed here before it can enter Boost.Thread, so it may be useful for you to watch that process unfold to give you an idea of what may be involved with your patchset as a good chunk of yours also involves Boost.Thread. You might see something next week or so, or after the C++ Now conference. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Tue, Apr 29, 2014 at 2:12 PM, Niall Douglas
BTW, I'll shortly be coming to this list with a new sync object for Boost.Thread called a "permit object" which wraps the failed POSIX pthreads permit object proposal for C11 which solves some of the problems of using condition variables directly. It looks a bit like half of a Win32 event object, but has stronger guarantees. Anyway it'll need to be reviewed here before it can enter Boost.Thread, so it may be useful for you to watch that process unfold to give you an idea of what may be involved with your patchset as a good chunk of yours also involves Boost.Thread. You might see something next week or so, or after the C++ Now conference.
<offtopic> I believe, the general target for low-level thread synchronization should be Boost.Sync. It's a little in a hanging state now, but in the long term it should supersede Boost.Thread synchronization primitives. That said, I'm not aware of "permit objects", so I don't know how well it would fit in Boost.Sync. </offtopic>
On 29 Apr 2014 at 16:49, Andrey Semashev wrote:
BTW, I'll shortly be coming to this list with a new sync object for Boost.Thread called a "permit object" which wraps the failed POSIX pthreads permit object proposal for C11 which solves some of the problems of using condition variables directly.
<offtopic> I believe, the general target for low-level thread synchronization should be Boost.Sync. It's a little in a hanging state now, but in the long term it should supersede Boost.Thread synchronization primitives. That said, I'm not aware of "permit objects", so I don't know how well it would fit in Boost.Sync. </offtopic>
I should stress what I'm about to say is too early, because the Boost permit object is not yet ready, so please wait until next week for further discussion. However, I can tell you that the permit object implementation remains a completely standalone new POSIX pthreads object written in C. All the proposed boost::permit<> object does is to wrap that C object - and in fact, boost/thread/permit.hpp is quite literally a copy and paste of boost/thread/posix/condition_variable.hpp with every instance of pthread_cond_whatever replaced with pthread_permit_whatever. And of course a few small modifications to allow a pthread API to work correctly on Windows (the C permit object works on Windows) and to support thread interruptions etc. In other words, if you wanted to add the permit to Boost.Sync, it ought to be absolutely trivial. Whatever refactor you're doing for condition_variable (POSIX implementation) you repeat on permit, and you're done. Please do wait till next week though. I am currently writing a load soak test for Boost.Thread which tests mutexes, condvars and permits for perfection under heavy CPU load sustained over minutes or hours. As you may know, there have been some problems with Thread on Mac OS X, hopefully this test might illuminate the cause. I also don't want to bring boost::permit<> to here until I can prove it is perfect and has significant advantages over condvars for its particular use cases. As you know, it is extremely easy to accidentally have some extremely rare race condition in threading primitives, so on those I am extra special cautious. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Please do wait till next week though. I am currently writing a load soak test for Boost.Thread which tests mutexes, condvars and permits for perfection under heavy CPU load sustained over minutes or hours. As you may know, there have been some problems with Thread on Mac OS X, hopefully this test might illuminate the cause. I also don't want to bring boost::permit<> to here until I can prove it is perfect and has significant advantages over condvars for its particular use cases. As you know, it is extremely easy to accidentally have some extremely rare race condition in threading primitives, so on those I am extra special cautious.
Thread is probably the last of the Boost libraries I will submit my contribution to since it depends on some of the others. I'm probably going to start with build, config, and test. Steve _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost SMime.p7s (8K) <http://boost.2283326.n4.nabble.com/attachment/4661816/0/SMime.p7s>; -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Yes I work with Artur on several projects. Thanks for information and help. Steve -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 04/25/2014 10:02 AM, stgates wrote:
Hi,
I work for Microsoft and we’ve been taking a look at making a some of the libraries in Boost work in the Windows 8 store and phone 8 runtime environment (WinRT). <snip>
Well, color me impressed! As a former MS employee who had to do battle with lawyers to get any source code released publicly (back around 2000), I'm really pleased at this turn-around. THANK YOU for contributing back. Eric
For those interested some of these changes have made it back into Boost now. Here is blog post http://blogs.msdn.com/b/vcblog/archive/2014/07/18/using-boost-libraries-in-w... explaining how to use and including vcvars setup scripts for Windows Phone 8.1 which were missing from Visual Studio 2013. Steve -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 7/21/2014 3:03 PM, stgates wrote:
For those interested some of these changes have made it back into Boost now. Here is blog post http://blogs.msdn.com/b/vcblog/archive/2014/07/18/using-boost-libraries-in-w... explaining how to use and including vcvars setup scripts for Windows Phone 8.1 which were missing from Visual Studio 2013.
Have any of the regression tests been testing your changes in the 'develop' branch ? In particular have any further tests for the libraries which you mention in your blog been made specifically to test their integration with Windows Store and Windows Phone applications ?
I have been running the tests locally myself. Now that the changes to Boost.Build for targeting have been accepted I'm in the process of making contributions for running tests. Once that is done it will be possible to run tests targeting Windows Store and Phone just like is done for the Win32 desktop. I haven't added any new tests. I'm trying to make sure to keep the tests following the Boost workflow of being able to automatically executed as part of the build. -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 07/21/2014 07:01 PM, stgates wrote:
I have been running the tests locally myself. Now that the changes to Boost.Build for targeting have been accepted I'm in the process of making contributions for running tests. Once that is done it will be possible to run tests targeting Windows Store and Phone just like is done for the Win32 desktop.
It would be great to have tests on 'develop' which can show some of the integration of Boost with Windows Store and Phone.
I haven't added any new tests. I'm trying to make sure to keep the tests following the Boost workflow of being able to automatically executed as part of the build.
That's understandable. I am just concerned that the integration of Boost with Windows Store and Phone be tested on 'develop' with some real meaningful tests, as well as regression tested on 'develop' by someone, even if it yourself representing Microsoft's efforts, before it is ever merged to 'master' and becomes part of some future release of Boost or individual Boost libraries. That is the normal workflow in Boost before anything ever gets merged to the 'master' release.
I agree the changes need testing. I have one pending pull request on Boost.Test that helps with running tests. https://github.com/boostorg/test/pull/9 Next I'm working on one for Boost.Build to also help with execution of tests. This will enable running the automated Boost tests covering the Windows Runtime code paths. In addition a sample/example style test could also be created, but it is unlikely it would be runnable in an automated fashion. -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 7/22/2014 1:41 PM, stgates wrote:
I agree the changes need testing. I have one pending pull request on Boost.Test that helps with running tests.
https://github.com/boostorg/test/pull/9
Next I'm working on one for Boost.Build to also help with execution of tests. This will enable running the automated Boost tests covering the Windows Runtime code paths. In addition a sample/example style test could also be created, but it is unlikely it would be runnable in an automated fashion.
If you and/or Microsoft could add some sort of periodic regression tests to the Boost testing matrix based on the work done to allow Boost libraries to work with Windows Store and Windows Phone I am sure it would be helpful to all Boost developers, especially to those whose libraries are used by the Microsoft technologies. I am pretty sure that one can create a regression test focusing on only a subset of libraries needing testing in a particular environment ( Windows 8 and 8.1 in your case with VC++ 11 and 12 I am guessing ).
On Tue, Jul 22, 2014 at 1:11 PM, Edward Diener
On 7/22/2014 1:41 PM, stgates wrote:
I agree the changes need testing. I have one pending pull request on Boost.Test that helps with running tests.
https://github.com/boostorg/test/pull/9
Next I'm working on one for Boost.Build to also help with execution of tests. This will enable running the automated Boost tests covering the Windows Runtime code paths. In addition a sample/example style test could also be created, but it is unlikely it would be runnable in an automated fashion.
I am pretty sure that one can create a regression test focusing on only a subset of libraries needing testing in a particular environment ( Windows 8 and 8.1 in your case with VC++ 11 and 12 I am guessing ).
Yes, the testing scripts at root/status supports options for limiting which libraries are tested (--limit-tests= option). And you can pass those options to the top-level regression script with the "--bjam-options=BJAM_OPTIONS" option. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 21 Jul 2014 at 18:00, Edward Diener wrote:
On 7/21/2014 3:03 PM, stgates wrote:
For those interested some of these changes have made it back into Boost now. Here is blog post http://blogs.msdn.com/b/vcblog/archive/2014/07/18/using-boost-libraries-in-w... explaining how to use and including vcvars setup scripts for Windows Phone 8.1 which were missing from Visual Studio 2013.
Have any of the regression tests been testing your changes in the 'develop' branch ? In particular have any further tests for the libraries which you mention in your blog been made specifically to test their integration with Windows Store and Windows Phone applications ?
Steve's pull request for Boost.Thread is being held back by me until the 1.57 release as I currently don't have the CI facilities to verify for myself it works to my satisfaction. Hell, I don't even have AFIO being CI tested right now, modularisation foobared everything, but the CI orchestration work being done for AFIO will be reusable for Boost.Thread. And my Windows CI is now Win8.1 instead of XP, so now I can bring VS2012 and VS2013 into the soak test runs. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 07/21/2014 08:09 PM, Niall Douglas wrote:
On 21 Jul 2014 at 18:00, Edward Diener wrote:
On 7/21/2014 3:03 PM, stgates wrote:
For those interested some of these changes have made it back into Boost now. Here is blog post http://blogs.msdn.com/b/vcblog/archive/2014/07/18/using-boost-libraries-in-w... explaining how to use and including vcvars setup scripts for Windows Phone 8.1 which were missing from Visual Studio 2013.
Have any of the regression tests been testing your changes in the 'develop' branch ? In particular have any further tests for the libraries which you mention in your blog been made specifically to test their integration with Windows Store and Windows Phone applications ?
Steve's pull request for Boost.Thread is being held back by me until the 1.57 release as I currently don't have the CI facilities to verify for myself it works to my satisfaction.
Boost could really do with the idea that we should be able to run and publish a regression test for some library that is not either the 'develop' or 'master' branch. That way someone with facilities to test a change could publish regression tests based on that change for others, like yourself in this case, who may want to accept a pull request but naturally needs to know that it tests OK before doing so. While pull requests are a good idea, having to blindly accept one at any time without verifying it for oneself is not as I am sure everyone knows. So I fully understand your problem, but we need a more generalized solution to it. Maybe someone on the Boost Build/Regression Tests side of things would know how to setup and publish a regression test for a single library off of some non-'develop' and non-'master' branch so that the test results are accessible to others.
Hell, I don't even have AFIO being CI tested right now, modularisation foobared everything, but the CI orchestration work being done for AFIO will be reusable for Boost.Thread. And my Windows CI is now Win8.1 instead of XP, so now I can bring VS2012 and VS2013 into the soak test runs.
I am not even on Win 8 yet, but luckily the latest Visual Studio releases still run under Windows 7. But of course I can't test new Windows 8 features as they relate to Boost until I install Win 8 ( or Win 8.1 ).
On 21 Jul 2014 at 22:52, Edward Diener wrote:
Steve's pull request for Boost.Thread is being held back by me until the 1.57 release as I currently don't have the CI facilities to verify for myself it works to my satisfaction.
Boost could really do with the idea that we should be able to run and publish a regression test for some library that is not either the 'develop' or 'master' branch. That way someone with facilities to test a change could publish regression tests based on that change for others, like yourself in this case, who may want to accept a pull request but naturally needs to know that it tests OK before doing so. While pull requests are a good idea, having to blindly accept one at any time without verifying it for oneself is not as I am sure everyone knows. So I fully understand your problem, but we need a more generalized solution to it.
Both Jenkins and Travis are very easily configured to automatically test pull requests and report back onto Github whether they are good or not.
Maybe someone on the Boost Build/Regression Tests side of things would know how to setup and publish a regression test for a single library off of some non-'develop' and non-'master' branch so that the test results are accessible to others.
Jenkins also publishes Boost.Build results just fine. Jenkins has a RESTful API which lets some central server interrogate it for results for some set of projects. As does Travis, incidentally. You probably see where I'm going with this.
Hell, I don't even have AFIO being CI tested right now, modularisation foobared everything, but the CI orchestration work being done for AFIO will be reusable for Boost.Thread. And my Windows CI is now Win8.1 instead of XP, so now I can bring VS2012 and VS2013 into the soak test runs.
I am not even on Win 8 yet, but luckily the latest Visual Studio releases still run under Windows 7. But of course I can't test new Windows 8 features as they relate to Boost until I install Win 8 ( or Win 8.1 ).
I *believe* that the WinRT SDK needs Win8 minimum. It certainly did when I worked at BlackBerry, I got to spend a week at home using my own computer because BlackBerry didn't have a single Windows 8 machine to hand at that time :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 7/22/2014 6:22 AM, Niall Douglas wrote:
On 21 Jul 2014 at 22:52, Edward Diener wrote:
Steve's pull request for Boost.Thread is being held back by me until the 1.57 release as I currently don't have the CI facilities to verify for myself it works to my satisfaction.
Boost could really do with the idea that we should be able to run and publish a regression test for some library that is not either the 'develop' or 'master' branch. That way someone with facilities to test a change could publish regression tests based on that change for others, like yourself in this case, who may want to accept a pull request but naturally needs to know that it tests OK before doing so. While pull requests are a good idea, having to blindly accept one at any time without verifying it for oneself is not as I am sure everyone knows. So I fully understand your problem, but we need a more generalized solution to it.
Both Jenkins and Travis are very easily configured to automatically test pull requests and report back onto Github whether they are good or not.
Sounds like a firm of lawyers, "Jenkins and Travis" <g>. I will look at them and see what they offer. Thanks !
Maybe someone on the Boost Build/Regression Tests side of things would know how to setup and publish a regression test for a single library off of some non-'develop' and non-'master' branch so that the test results are accessible to others.
Jenkins also publishes Boost.Build results just fine. Jenkins has a RESTful API which lets some central server interrogate it for results for some set of projects. As does Travis, incidentally.
You probably see where I'm going with this.
Maybe this can be integrated with Boost regression testing in some way that provides results for a branch that is not 'develop' or 'master', and can be used by anyone with a pull request.
Hell, I don't even have AFIO being CI tested right now, modularisation foobared everything, but the CI orchestration work being done for AFIO will be reusable for Boost.Thread. And my Windows CI is now Win8.1 instead of XP, so now I can bring VS2012 and VS2013 into the soak test runs.
I am not even on Win 8 yet, but luckily the latest Visual Studio releases still run under Windows 7. But of course I can't test new Windows 8 features as they relate to Boost until I install Win 8 ( or Win 8.1 ).
I *believe* that the WinRT SDK needs Win8 minimum. It certainly did when I worked at BlackBerry, I got to spend a week at home using my own computer because BlackBerry didn't have a single Windows 8 machine to hand at that time :)
That is why I am mildly concerned about changes to Boost for Windows Store and Phone apps. They need to be tested like anything else to see if they work properly.
I give a plus one to Jenkins as well, I've used it in another product. It's worked well for me, setting up things like cross platform gated checkin builds and test runs. -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows-... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (8)
-
Andrey Semashev -
Edward Diener -
Eric Niebler -
Glen Fernandes -
Niall Douglas -
Rene Rivera -
Rob Stewart -
stgates