I don't know if it is suitable to open the issue here, but I would like to ask if the MSYS2 team interested in introducing an environment with MSVC ABI. There're some advantages with MSVC ABI:
- Some commercial libraries only distributes with MSVC ABI. For example, CUDA. An MSVC-compatible environment could distribute the open-sources libraries with CUDA support (pytorch, maybe).
- Many open-source libraries also assume MSVC as the compiler on Windows. Build scripts need less modifications to compile.
- Many open-source libraries doesn't provide installers. Only
vcpkg could handle them, but it costs a lot time and the compilation might fail. I think pacman is better than vcpkg.
The cc of such environment might be clang, or a wrapper of MSVC (a small executable, trying to find the real MSVC through vswhere.exe). The Windows SDK import libraries could be either the open-sourced one, or by searching the installed one in Program Files.
I don't know if it is suitable to open the issue here, but I would like to ask if the MSYS2 team interested in introducing an environment with MSVC ABI. There're some advantages with MSVC ABI:
vcpkgcould handle them, but it costs a lot time and the compilation might fail. I think pacman is better than vcpkg.The
ccof such environment might be clang, or a wrapper of MSVC (a small executable, trying to find the real MSVC throughvswhere.exe). The Windows SDK import libraries could be either the open-sourced one, or by searching the installed one inProgram Files.