Add Windows CI

[jhale]

• Brings back macOS test.
• Makes pygraphviz truly optional.
• All C builds done in C17 standard mode.
• Support for Visual C compiler on Windows (does not support _Complex).
• Does not preclude use of ffcx on Windows for complex code generation with another compiler invoked via e.g. CMake or at the command line.

[jhale]

@minrk Could you try this one on Conda? The thing that might be 'difficult' here is the use of CFFI.

Edit: I have a question; will our end users need to install MSVC, or is there a possibility option to use clang on Windows via CFFI?

[minrk]

is there a possibility option to use clang on Windows via CFFI?

clang is available on Windows, though I've never used it, so don't know what the implications would be. I believe if you use msvc, it would means folks need to install a compiler outside of conda. I think clang should avoid this, but there may still be an SDK requirement, I'm not sure.

Question is: what packages would need to use clang:

• all fenics packages (basix, dolfinx)?
• none, just the runtime requirement?

It's going to take me a bit to figure out testing beyond basix on conda-forge, since the dependency means the unreleased builds need to be published somewhere that's not the conda-forge default channel, so downstream can depend on them.

[jhale]

is there a possibility option to use clang on Windows via CFFI?

clang is available on Windows, though I've never used it, so don't know what the implications would be. I believe if you use msvc, it would means folks need to install a compiler outside of conda. I think clang should avoid this, but there may still be an SDK requirement, I'm not sure.

Question is: what packages would need to use clang:

• all fenics packages (basix, dolfinx)?
• none, just the runtime requirement?

It's going to take me a bit to figure out testing beyond basix on conda-forge, since the dependency means the unreleased builds need to be published somewhere that's not the conda-forge default channel, so downstream can depend on them.

I took a look at how FFCx is currently using cffi.compile() and on Windows MSVC is the only option without implementing our own JIT compiler wrappers (which I don't want to do, unless it is absolutely necessary) - so users will need to install MSVC. Most of our users will be covered by the Community License anyway.

This issue (how can I use a different compiler with cffi?) is discussed here:

https://foss.heptapod.net/pypy/cffi/-/issues/560

Our only runtime dependency on a compiler is when using CFFI via FFCx, but it is an important core feature and cannot be skipped.

https://github.com/conda-forge/cffi-feedstock/blob/main/recipe/meta.yaml

You can see here there is no runtime dependency on a C compiler, so it must be assumed provided by the system.

[jhale]

On the last point, @chrisrichardson has a Windows machine setup for development, so perhaps we could work together to try a conda build locally?

[minrk]

That's possible. I'm going to try to download the artifacts from unmerged conda-forge CI and upload them to my channel, which should work, but there seems to be a hiccup with downloading the artifacts right now.

[minrk]

I asked, and even with clang, users would need Windows SDKs to compile, so there would be little benefit to depending on clang instead of msvc.

[jhale]

Thanks! I read the thread - we can revisit clang as an option at a later date. For now MSVC2022 using cl.exe will be the only officially supported options on Windows.

[jhale]

Just to clarify a few points from https://conda.discourse.group/t/runtime-requirement-for-c-compiler-on-windows/614/3

• FFCx has a runtime dependency on a C (not C++) compiler implicitly via CFFI when using our JIT compilation.
• Our demo runner for testing has a dependency on a C compiler, but that is not strictly necessary for a user install. If a user creates .c and .h files via ffcx command line they will need a C compiler to build something with them but I hope that is self-explanatory.
• We do not link with anything other than the standard links required by C/CFFI (stdc, Python) etc. and libm (only on Linux/Unix platforms). So there is no linking with Basix or DOLFINx.

[minrk]

Thanks! That clarifies things.

[jhale]

Great. This patch is now ready for final review and preliminary testing in Conda.

[minrk]

Haven't quite worked out all the kinks in getting basix from my channel into conda-forge CI, but so far looks like ffcx (d3ecb540f2a9761f09dfac6576f41300da06b7a6) works fine on Windows in conda-forge with no modifications.

[minrk]

All tests pass on conda on Windows without any special handling: https://github.com/conda-forge/fenics-ffcx-feedstock/pull/7

Windows folks should be able to test installation with conda with:

conda install -c conda-forge -c minrk/label/fenics-windows fenics-ffcx=0.9.0.dev

[jhale]

This is now ready to merge.