Add a new target which generates a C-only API shared library, compatible with MSVC

[fabiocannizzo]

This PR allows to use and link the library both in Linux and Windows (also compatible with MSVC).

It exports most of the functions using a extern-C api, so there are no issue with inconsistent name mangling used by different compilers. Exceptions and memory allocations do not cross the shared library boundary, avoiding possible inconsistency of binary API.

When the target is Windows, the compiler of choice is clang with mingw. Compiling with gcc is not a viable option because of a long standing bug related to alignment of objects requiring 32-bytes alignment (see mingw-w64/mingw-w64#115). The generated DLL is self-contained, i.e. there are no other DLL dependencies (other than the kernel ones), so there is no need to distribute mingw toolchain DLLs.

The C++ standard is upgraded to C+20, which allows to use more portable version for the unlikely attribute.

There are a few more explicit uses of force inline. These are generally redundant, but, in some cases, they may help a bit when compiling for Windows platform, where by default AVX2 registers are not passed via registers.

Instructions on how to compile and available targets and cross compilation host platforms are in README.md.

A test file smoke.cpp to use the API is available in the make-c-api folder.

Github workflow files are also provided, to test various way to build the library and run the test.

[r-devulap]

Hi @fabiocannizzo, I had a quick question: is the purpose of this PR to build this library on Windows? If that’s the case, do we also need to expose all the APIs in C? The library is primarily written in C++, and I’m not sure we have the bandwidth right now to fully support a C interface.

[r-devulap]

Also:

The C++ standard is upgraded to C+20, which allows to use more portable version for the unlikely attribute.

Unfortunately, this creates a compatibility issue: NumPy, one of the main users of this library, is still on C++17. We can't move to C++-20 just yet.

[fabiocannizzo]

Unfortunately, this creates a compatibility issue: NumPy, one of the main users of this library, is still on C++17. We can't move to C++-20 just yet.

The upgrade to C++20 has purely cosmetic reason, to handle the [unlikely] attribute in a portable manner. That commit can be easily omitted.

[fabiocannizzo]

Hi @fabiocannizzo, I had a quick question: is the purpose of this PR to build this library on Windows? If that’s the case, do we also need to expose all the APIs in C? The library is primarily written in C++, and I’m not sure we have the bandwidth right now to fully support a C interface.

The purpose is to build it the library for Windows and use it with MSVC.
The only way I found to build it for Windows is with mingw-clang, because mingw gcc has bugs and msvc does not understand the most advanced intrinsics. Unfortunately the native C++ binary API generated by mingw-clang is incompatible with MSVC, hence the need for the C-API. Since I would also like to write portable code against the same API, I made the C-API available also on Linux with gcc.

The C-API is provided as an auto-generated minimally intrusive light-weight wrapper. I would be happy to schedule a f2f session and walk you through, if that is useful.

[r-devulap]

The purpose is to build it the library for Windows and use it with MSVC.

See #220. I was able to update meson.build to build the library with MSVC. Its still work in progress and doesnt build tests and benchmarks yet. But I think we can build with MSVC without having to expose C-APIs.

[r-devulap]

@fabiocannizzo could you try #220 and see if you can build on windows using MSVC?

[fabiocannizzo]

@fabiocannizzo could you try #220 and see if you can build on windows using MSVC?

@r-devulap, I will test and revert. What is the meson configuration command line to use? In which shell on windows should it run: the MSVC x86 native cmd prompt?