MSVC build

[timfish]

Experimental MSVC build.

[yorickpeterse]

How does this compare to using CMake, or would that still require Visual Studio to be installed?

Also did you mean to include some of the header files and such in the MSVC build directory? If so, are they different from libffi 3.3 and if so how/why? I think in general it would be better to copy files over instead of including them in Git directly, otherwise they can easily get out of sync.

[timfish]

Sorry, I was in a rush earlier and didn't have enough time to give a full explanation.

The aim of this PR is to give build support support for the *-pc-windows-msvc toolchains without requiring any other prerequisites. These toolchains are the default on Windows and the only prerequisite they require is a fairly recent install of the free Visual Studio Community Edition (or at least the c++ build tools).

The intention was to include the header files as this is already the procedure for the official libffi aarch64 msvc build. My understanding is that this is because Windows + Visual Studio do not have the required tools to pre-process the header files 🤦‍♂️. This is also the case for the winlibs/libffi fork which is used in PHP and other projects. It's actually barely a fork, they just patch the VS files and headers on upgrade.

The headers I've included are from the 3.3 update to winlibs and ffi.h had minor modifications to enable ffi_type_longdouble which is required by libffi-sys-rs and they had it disabled.

This currently only builds with Visual Studio 2019 because the project file I put together is for that version. I needed to get this building for my project and that was the quickest route!

I'm going to look into using the full cc::Build API as this would mean that the Visual Studio project files can be dropped and it'll correctly handle debug/release/arch etc. Eventually the AppVeyor build matrix will include 2017+2019 to confirm this is all working.

[tov]

Hey @timfish, thanks for doing this! If the headers are from winlibs libffi, would it make sense to depend on that rather than vendoring the files? Or better yet, is there a binary distribution of libffi for Windows?

[timfish]

Unfortunately, ffi.h in winlibs has already been pre-processed with ffi_type_longdouble disabled and this is required for libffi-rs. The version in this PR has #if 0 replaced with #if 1 in these three locations:

• https://github.com/winlibs/libffi/include/ffi.h#L206
• https://github.com/winlibs/libffi/include/ffi.h#L215
• https://github.com/winlibs/libffi/include/ffi.h#L497

I have not seen any binary distribution for Windows.

[timfish]

Is there anything else I can do to help get this merged?

The vendored files appear to be an inevitable consequence of supporting msvc. We're writing a library that needs to support all tier 1 toolchains so I'm happy to commit to maintaining the vendored files and the msvc build.

It might be possible to generate the vendored headers using a build step in CI and commit them back to the repository but this could be more hassle than it's worth.

It's worth noting that the tests in this repository do not test whether static linking will be successful. It's possible to have the libffi-sys-rs tests passing but linking fail, so libffi-rs should ideally include Windows builds too to test this.

[tov]

I'm testing this now, and when it passes I’ll release it as libffi-sys 0.9.1.

As for testing static linking, do you just mean that I should test the libffi crate on Windows as well? Or is it necessary to specify static linking? (Or do you mean that CI for libffi-sys should check that libffi can link against it still?)

[timfish]

Yes, ideally the libffi crate should be tested on Windows too to confirm that the libffi-sys links correctly and tests pass. If I get a chance later in the week I'll do a PR to test on Win/Mac/Linux using Github Actions. This is how I'm currently building a crate on all three with MSRV, stable and nightly. It also runs on a daily schedule so I get notified when warnings appear on nightly.