[winrt support] Adding support for Windows 8 store/phone to Boost libraries

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[winrt support] Adding support for Windows 8 store/phone to Boost libraries

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). 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.
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Rob Stewart-6
On April 25, 2014 1:02:09 PM EDT, stgates <[hidden email]> 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).

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)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Niall Douglas
In reply to this post by stgates
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/





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

stgates
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.

> 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
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Eric Niebler-4
In reply to this post by stgates
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Glen Fernandes
In reply to this post by stgates
On Mon, Apr 28, 2014 at 11:14 AM, stgates <[hidden email]> wrote:
>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Niall Douglas
In reply to this post by stgates
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/





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Andrey Semashev-2
On Tue, Apr 29, 2014 at 2:12 PM, Niall Douglas
<[hidden email]> 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. 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>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Niall Douglas
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/





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

stgates
In reply to this post by Niall Douglas
Yes I work with Artur on several projects. Thanks for information and help.

Steve
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

stgates
In reply to this post by Niall Douglas
> 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>

Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

stgates
In reply to this post by stgates
For those interested some of these changes have made it back into Boost now. Here is blog post explaining how to use and including vcvars setup scripts for Windows Phone 8.1 which were missing from Visual Studio 2013.

Steve
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Edward Diener-3
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-windows-store-and-phone-applications.aspx>
> 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 ?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

stgates
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.
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Niall Douglas
In reply to this post by Edward Diener-3
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-windows-store-and-phone-applications.aspx>
> > 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/




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Edward Diener-3
In reply to this post by stgates
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.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Edward Diener-3
In reply to this post by Niall Douglas
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-windows-store-and-phone-applications.aspx>
>>> 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 ).


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Niall Douglas
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/




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

Edward Diener-3
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [winrt support] Adding support for Windows 8 store/phone to Boost libraries

stgates
In reply to this post by Edward Diener-3
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.

12