-
-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Windows CI #689
Add Windows CI #689
Conversation
jhale
commented
Apr 30, 2024
•
edited
Loading
edited
- 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.
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:
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 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. |
On the last point, @chrisrichardson has a Windows machine setup for development, so perhaps we could work together to try a conda build locally? |
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. |
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. |
Thanks! I read the thread - we can revisit clang as an option at a later date. For now MSVC2022 using |
Just to clarify a few points from https://conda.discourse.group/t/runtime-requirement-for-c-compiler-on-windows/614/3
|
Thanks! That clarifies things. |
Great. This patch is now ready for final review and preliminary testing in Conda. |
Haven't quite worked out all the kinks in getting basix from my channel into conda-forge CI, but so far looks like ffcx (d3ecb54) works fine on Windows in conda-forge with no modifications. |
demo/test_demos.py
Outdated
assert ( | ||
os.system( | ||
f"cd {demo_dir} && " | ||
f"gcc -I../ffcx/codegeneration " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
f"gcc -I../ffcx/codegeneration " | |
f"cc -I../ffcx/codegeneration " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw, I think cc = os.environ.get("CC", sysconfig.get_config_var("CC"))
is more likely to get the right thing and accepts the ubiquitous standard env override.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On balance I'd rather go with a combination cc = os.environ.get("CC", "cc")
- what Python thinks about how to build extension modules doesn't seem hugely relevant to this test which is about our C/C++ pipeline.
All tests pass on conda on Windows without any special handling: conda-forge/fenics-ffcx-feedstock#7 Windows folks should be able to test installation with conda with:
|
This is now ready to merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
@@ -22,40 +22,75 @@ jobs: | |||
matrix: | |||
os: [ubuntu-latest] | |||
python-version: ['3.9', '3.10', '3.11', '3.12'] | |||
include: | |||
- os: windows-latest | |||
python-version: '3.11' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to test with 3.11 rather than 3.12?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, just providing some coverage because I will run against 3.12 on Windows elsewhere, e.g. DOLFINx.
@@ -64,10 +99,15 @@ jobs: | |||
# Use always() to always run this step to publish test results | |||
# when there are test failures | |||
if: always() | |||
|
|||
- name: Setup cl.exe (Windows) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is cl.exe
clang?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's Microsoft's Visual C Compiler (MSVC).
Note that Microsoft also offer clang-cl.exe
which is a wrapper over clang
to a provide drop-in replacement for cl.exe
. This looked exciting in the first instance, because it supports _Complex
. However, clang-cl.exe
is not supported by Conda or CFFI, where MSVC is the only supported option today on Windows.
I did however add a test of clang-cl.exe
to our C demo tests, and it works fine.
@@ -17,6 +17,10 @@ | |||
@pytest.mark.parametrize("scalar_type", ["float64", "float32", "complex128", "complex64"]) | |||
def test_demo(file, scalar_type): | |||
"""Test a demo.""" | |||
if sys.platform.startswith("win32") and "complex" in scalar_type: | |||
# Skip complex demos on win32 | |||
pytest.skip(reason="_Complex not supported on Windows") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What a pain . . . .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, MSVC's lack of _Complex
support has been the only major issue blocking a straightforward port.