Add winapi-rs to set of benchmarks

[michaelwoerister]

Opening an issue so this doesn't fall off our radar.

cc @Mark-Simulacrum @retep998

[Mark-Simulacrum]

Just as a note, in order for try builds to work with this we'd need some mechanism to build those on appveyor as well, which could be problematic...

[retep998]

Unless we configured the travis builders to build the standard library rlibs for windows when doing a try build. It has no C dependencies for pc-windows-msvc so it should be able to work.

[Mark-Simulacrum]

Seems like something we should do, then, since it'll be fairly low-overhead to produce just the std rlibs on try builds.

[mati865]

Almost any crate could be cross compiled to windows-gnu from Linux host. Building the std is also simple since MinGW can be installed from the repo. I'll do the investigation and report hopefully later today.

[mati865]

Okay so without modifying try builds there are 2 possibilities that will work with no_std rlib crates like winapi-rs:

• cargo xbuild --target x86_64-pc-windows-{gnu,msvc} - first run will build required sysroot crates to target/sysroot/<triple> and the crate itself to target/<triple>. Removing target/<triple> and rerunning the command will reuse sysroot from previous run, this time it could be benchmarked although there will be some overhead since it's external tool.
• cargo build --target x86_64-pc-windows-{gnu,msvc} -Z build-std - similar to cargo-xbuild but available in bare Cargo. Sysroot crates and the crate itself are built into target/sysroot/<triple>, I don't know if there is reasonable way to keep old sysroot binaries and fully rebuild the crate.

Another solution would be to modify Linux dist builder for try builds only by installing mingw-w64 and building x86_64-pc-windows-gnu std. That would also allow benchmarking of various std dependant crate types (like bins, dylibs, ...). The hard part here is getting functional mingw-w64 toolchain since that builder is using an ancient CentOS 5 but I should be able to provide it once I get enough time.

[Mark-Simulacrum]

We currently already build std on perf.rlo before every benchmark (used to be for reproducibility reasons, I believe currently not technically needed). I would be fine adding a mingw-using build to that that's optional and enabled on perf.rlo's official collection by default.

I don't think we need xbuild to do so, we can probably just add on to the existing support. I would be happy to take a PR doing so.

[rylev]

We may want to consider having the windows crate in addition to winapi. It's also a large code base, but it's sufficiently different in design that I think having it in addition would be useful.

[michaelwoerister]

Yes, definitely!