Look for pthreads-win32 when building with MSVC

[sethk]

Note that MSYS64 identifies itself to Meson as 'cygwin', and has a pthreads-compliant threads implementation.

The sources for pthreads-win32 were once included in this project as a requirement for MSVC, but never made it into the Meson config and were removed at some point (I don't know which happened first).

[1480c1]

Note that MSYS64 identifies itself to Meson as 'cygwin', and has a pthreads-compliant threads implementation.

Just to clarify, when you mean MSYS64, do you mean msys2's https://packages.msys2.org/base/meson?

[sethk]

Oh, that's a good question actually. I now have multiple versions of Meson installed, and they are giving different answers, and you are correct that the MSYS2 version is the one identifying itself as 'cygwin'. Using the term MSYS64 is confusing and I wish I could amend my commit message. Because my change tests for both the system and compiler, it should be correct.

If I follow the letter of the law from https://github.com/Netflix/vmaf/blob/master/resource/doc/windows.md , then I should be using the MinGW-w64 version, but I already had an older version of meson, ninja, and nasm installed into my MSYS2 base environment.

Here's what all the versions of Meson on my system are reporting:

Version installed from meson-1.6.1-64.msi, configured to use MSVC with a native.ini file:

% /c/Program\ Files/Meson/meson.exe --version
1.6.1
% /c/Program\ Files/Meson/meson.exe introspect libvmaf/build --machines
{"host": {"system": "windows", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "windows", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "obj"}, "build": {"system": "windows", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "windows", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "obj"}, "target": {"system": "windows", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "windows", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "obj"}}

Old version installed into MSYS2, configured to build using GCC:

% /usr/bin/meson --version
1.6.0
% /usr/bin/meson introspect libvmaf/build --machines
{"host": {"system": "cygwin", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "cygwin", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "o"}, "build": {"system": "cygwin", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "cygwin", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "o"}, "target": {"system": "cygwin", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "cygwin", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "o"}}

New version from MinGW-w64:

% /mingw64/bin/meson.exe --version
1.7.0
% /mingw64/bin/meson.exe introspect libvmaf/build --machines
{"host": {"system": "windows", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "windows", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "obj"}, "build": {"system": "windows", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "windows", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "obj"}, "target": {"system": "windows", "cpu_family": "x86_64", "cpu": "x86_64", "endian": "little", "kernel": "nt", "subsystem": "windows", "is_64_bit": true, "exe_suffix": "exe", "object_suffix": "obj"}}

[1480c1]

Okay, I was just a tad confused, since I normally associate the string (case-insensitive) "MSYS64" with C:\msys64 and don't immediately associate it with the MSYS environment. As a note, I don't compile with msvc, so I don't have any further comments.

[kylophone]

As a note, I don't compile with msvc.

Yes, I am in the same camp.

@sethk If we want to add support for MSVC, is this something that can be verified via CI?

[sethk]

As a note, I don't compile with msvc.

Yes, I am in the same camp.

I'm starting to see a pattern here guys. :)

@sethk If we want to add support for MSVC, is this something that can be verified via CI?

Theoretically yes, although installing Visual Studio on a headless system is a huge PITA. The last time I tried, it got stuck on some dialog box, despite all the --unattended flags and whatnot. I don't have any experience using it with GitHub Actions, maybe there is some provision for it. Or maybe clang-cl is the answer; I have no experience with that. I wonder how it deals with pthreads...

Bringing back MSVC support is not that far off, but it's gonna require 3-4 more patches from me that I need to clean up and test. I presume MSVC worked even after the transition to Meson due to the references to 'msvc' in the build config, and the presence of libvmaf/src/compat/msvc. If you guys would rather drop official support for MSVC/MSVS that would be fine, and you can close #1410, and I can maintain my own fork. The most controversial change I have is that MSVC's C11 implementation lacks variable length arrays, but they added support for enough of stdatomic.h recently that it can be used in place of libvmaf/src/compat/msvc/stdatomic.h with VS2022.

[Andarwinux]

If you're going to add MSVC support, why not just add a win32thread implementation?

[sethk]

If you're going to add MSVC support, why not just add a win32thread implementation?

I do think that would be ideal, but for my uses my only goal was to get it to compile. I presume due to the way that the pthreads-w32 sources were added to the project previously, that the work to implement win32 threads would be non-trivial.

I also want to stress that I'm not trying to add support for MSVC, I'm just trying to get it to work again the way it did before. And I have succeeded, using some quick-and-dirty hacks that I have been slowly turning into nice patches. The pthreads dependency is just one thing. :)