openmp issue on Windows

[jorisv]

When building on Windows, with clang-cl and conda-forge dependencies some tests fails:

• pinocchio-example-py-static-contact-dynamics
• pinocchio-test-py-bindings_dynamics

Error message is the following:

OMP: Error #15: Initializing libomp140.x86_64.dll, but found libomp.dll already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/

It's because the default numpy backend is mkl that use intel-openmp on Windows.

When using clang-cl, CMake will take openmp from the clang-cl installation: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/lib/x64/libomp.lib

This is a bad behavior since it hide openmp implementation by taking a non conda library as dependency.
In this case, this create a conflict with intel-openmp initialized by the mkl and make the tests fails.

There is two way to solve this issue:

1. Using intel-openmp

• Done on this branch: https://github.com/jorisv/jrl-cmakemodules/tree/topic/intel_openmp
• But this will block end user to choose a custom openmp implementation (intel-openmp should conflict orther impls conda-forge/intel_repack-feedstock#59)
• Also, llvm-openmp seem to be more widely used on Windows
• Last, linking against intel-openmp when using clang-cl and CMake is not standard

2. Using blis instead of mkl and use llvm-openmp

• Suggested here: Win: Alternative to MKL conda-forge/scipy-feedstock#257
• Done here: https://github.com/conda-forge/impactx-feedstock/blob/main/recipe/meta.yaml#L79
• But this will block end user to choose a custom blas implementation
• Also, it's impossible to install llvm-openmp with ipopt because of a conflict between openmp version used with a old flang version (Upgrade fortran compiler on Windows conda-forge/conda-forge-pinning-feedstock#5081)

Since the ipopt issue should be removed in few weeks we will take option 2 to solve the issue.

In the meantime, we will deactivate parallel build from the Windows CI.