Subject: Re: [boost] [winrt support] Adding support for Windows 8 store/phone to Boost libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-04-26 11:31:23
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/