F2PY and Windows#
Warning
F2PY support for Windows is not at par with Linux support, and
OS specific flags can be seen via python -m numpy.f2py
Broadly speaking, there are two issues working with F2PY on Windows:
the lack of actively developed FOSS Fortran compilers, and,
the linking issues related to the C runtime library for building Python-C extensions.
The focus of this section is to establish a guideline for developing and extending Fortran modules for Python natively, via F2PY on Windows.
Overview#
From a user perspective, the most UNIX compatible Windows development environment is through emulation, either via the Windows Subsystem on Linux, or facilitated by Docker. In a similar vein, traditional virtualization methods like VirtualBox are also reasonable methods to develop UNIX tools on Windows.
Native Windows support is typically stunted beyond the usage of commercial compilers.
However, as of 2022, most commercial compilers have free plans which are sufficient for
general use. Additionally, the Fortran language features supported by f2py
(partial coverage of Fortran 2003), means that newer toolchains are often not
required. Briefly, then, for an end user, in order of use:
- Classic Intel Compilers (commercial)
These are maintained actively, though licensing restrictions may apply as further detailed in F2PY and Windows Intel Fortran.
Suitable for general use for those building native Windows programs by building off of MSVC.
- MSYS2 (FOSS)
In conjunction with the
mingw-w64
project,gfortran
andgcc
toolchains can be used to natively build Windows programs.- Windows Subsystem for Linux
Assuming the usage of
gfortran
, this can be used for cross-compiling Windows applications, but is significantly more complicated.- Conda
Windows support for compilers in
conda
is facilitated by pulling MSYS2 binaries, however these are outdated, and therefore not recommended (as of 30-01-2022).- PGI Compilers (commercial)
Unmaintained but sufficient if an existing license is present. Works natively, but has been superseded by the Nvidia HPC SDK, with no native Windows support.
- Cygwin (FOSS)
Can also be used for
gfortran
. Howeve, the POSIX API compatibility layer provided by Cygwin is meant to compile UNIX software on Windows, instead of building native Windows programs. This means cross compilation is required.
The compilation suites described so far are compatible with the now
deprecated np.distutils
build backend which is exposed by the F2PY CLI.
Additional build system usage (meson
, cmake
) as described in
F2PY and Build Systems allows for a more flexible set of compiler
backends including:
- Intel oneAPI
The newer Intel compilers (
ifx
,icx
) are based on LLVM and can be used for native compilation. Licensing requirements can be onerous.- Classic Flang (FOSS)
The backbone of the PGI compilers were cannibalized to form the “classic” or legacy version of Flang. This may be compiled from source and used natively. LLVM Flang does not support Windows yet (30-01-2022).
- LFortran (FOSS)
One of two LLVM based compilers. Not all of F2PY supported Fortran can be compiled yet (30-01-2022) but uses MSVC for native linking.
Baseline#
For this document we will asume the following basic tools:
The IDE being considered is the community supported Microsoft Visual Studio Code
The terminal being used is the Windows Terminal
The shell environment is assumed to be Powershell 7.x
- Python 3.10 from the Microsoft Store and this can be tested with
Get-Command python.exe
resolving toC:\Users\$USERNAME\AppData\Local\Microsoft\WindowsApps\python.exe
The Microsoft Visual C++ (MSVC) toolset
With this baseline configuration, we will further consider a configuration matrix as follows:
Fortran Compiler |
C/C++ Compiler |
Source |
---|---|---|
Intel Fortran |
MSVC / ICC |
exe |
GFortran |
MSVC |
MSYS2/exe |
GFortran |
GCC |
WSL |
Classic Flang |
MSVC |
Source / Conda |
Anaconda GFortran |
Anaconda GCC |
exe |
For an understanding of the key issues motivating the need for such a matrix Pauli Virtanen’s in-depth post on wheels with Fortran for Windows is an excellent resource. An entertaining explanation of an application binary interface (ABI) can be found in this post by JeanHeyd Meneide.
Powershell and MSVC#
MSVC is installed either via the Visual Studio Bundle or the lighter (preferred)
Build Tools for Visual Studio with the Desktop development with C++
setting.
Note
This can take a significant amount of time as it includes a download of around 2GB and requires a restart.
It is possible to use the resulting environment from a standard command
prompt. However, it is more pleasant to use a developer powershell,
with a profile in Windows Terminal. This can be achieved by adding the
following block to the profiles->list
section of the JSON file used to
configure Windows Terminal (see Settings->Open JSON file
):
{
"name": "Developer PowerShell for VS 2019",
"commandline": "powershell.exe -noe -c \"$vsPath = (Join-Path ${env:ProgramFiles(x86)} -ChildPath 'Microsoft Visual Studio\\2019\\BuildTools'); Import-Module (Join-Path $vsPath 'Common7\\Tools\\Microsoft.VisualStudio.DevShell.dll'); Enter-VsDevShell -VsInstallPath $vsPath -SkipAutomaticLocation\"",
"icon": "ms-appx:///ProfileIcons/{61c54bbd-c2c6-5271-96e7-009a87ff44bf}.png"
}
Now, testing the compiler toolchain could look like:
# New Windows Developer Powershell instance / tab
# or
$vsPath = (Join-Path ${env:ProgramFiles(x86)} -ChildPath 'Microsoft Visual Studio\\2019\\BuildTools');
Import-Module (Join-Path $vsPath 'Common7\\Tools\\Microsoft.VisualStudio.DevShell.dll');
Enter-VsDevShell -VsInstallPath $vsPath -SkipAutomaticLocation
**********************************************************************
** Visual Studio 2019 Developer PowerShell v16.11.9
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
cd $HOME
echo "#include<stdio.h>" > blah.cpp; echo 'int main(){printf("Hi");return 1;}' >> blah.cpp
cl blah.cpp
.\blah.exe
# Hi
rm blah.cpp
It is also possible to check that the environment has been updated correctly
with $ENV:PATH
.
Windows Store Python Paths#
The MS Windows version of Python discussed here installs to a non-deterministic
path using a hash. This needs to be added to the PATH
variable.
$Env:Path += ";$env:LOCALAPPDATA\packages\pythonsoftwarefoundation.python.3.10_qbz5n2kfra8p0\localcache\local-packages\python310\scripts"