[DOC] How to find Windows compilers when using scikit-build with cibuildwheel

[bdice]

First, thanks so much to the authors of this package. It's excellent, has amazing docs, and is helping to resolve a major pain point for me as a maintainer. 🚀

I have been working on getting cibuildwheel to work with scikit-build on Windows for a simulation analysis package I maintain, freud. While I'm still working on the build process for making cibuildwheel work with Windows, I wanted to make an issue that specifically documents one of the steps that was difficult for me.

Problem

scikit-build wasn't able to find a working compiler because I had not activated "vcvarsall" or an equivalent form of environment configuration.

Solution

I'm using GitHub actions and needed to add this step before the cibuildwheel step, so that scikit-build and CMake could find the correct compilers: https://github.com/ilammy/msvc-dev-cmd

      # Configure compilers for Windows. Does nothing on Linux/Mac.
      - name: Enable Developer Command Prompt
        uses: ilammy/msvc-dev-cmd@v1

This is effectively equivalent to executing the "vcvarsall" script that sets environment variables for Visual C++ compilers, but persists between steps in GitHub Actions. This also circumvents the possible need for a CIBW_BUILD_WHEEL_COMMAND option as described in #151 because the environment variables persist without the need to call something immediately before pip wheel in the same step.

[joerick]

Hi @bdice ! Thanks for writing this up. We do have a reference to ilammy/msvc-dev-cmd in the docs, though it might be a little hard to find: https://cibuildwheel.readthedocs.io/en/stable/cpp_standards/#windows-and-python-27

Does the above fit your understanding of the problem? Or perhaps we need to add another reference elsewhere?

[bdice]

@joerick I did see that in the docs, but my package doesn't support 2.7 so I just ignored this part of the docs. 😬 Perhaps a solution would be to extract some of the more general tips for "building C++ Python extensions on Windows" that doesn't indicate that it only applies to Python 2.7? I could take a look at that and make (or review) a PR, if my understanding is correct.

[henryiii]

Scikit-build does not respect the setuptools compiler selection (which I'm hoping might be something I can change in the future), so it requires the MSVC environment to be setup if it has a compiler it doesn't by default look for (MSVC 2019 being a prime example).

[eudoxos]

Is there any workaround for this issue? I am already using ilammy/msvc-dev-cmd@v1 with skbuild-based ultra-simple setup.py, pyproject.toml and minimal CMakeLists.txt... and still getting:

          Generator
  
            Visual Studio 17 2022
  
          could not find any instance of Visual Studio.

[eudoxos]

For the record, perhaps it is useful for someone: I solved the issue by ilammy/msvc-dev-cmd@1 AND adding this parameter to skbuild.setup in setup.py:

cmake_args=(['-G','Visual Studio 16 2019'] if sys.platform=='win32' else [])

Explicitly specifying generator was necessary to avoid Ninja (the default of skbuild under Windows) which would erroneously mix MSVC c/c++ compilers with gfortran.exe (as there is no fortran compiler with MSVC), causing errors.

Specifically, Eigen3 CMake looks for fortran compiler during its configuration phase; it is okay if it is not found at all, as with VS generator, but it is not okay to find it and not being able to use it, as with Ninja generator which will pass MSVC options to gfortran.exe; this is the upstream Eigen3 issue.