Native build on Windows - #3309
Open
yorickreum wants to merge 2 commits into
Open
yorickreum wants to merge 2 commits into
yorickreum wants to merge 2 commits into
Conversation
oskooi
reviewed
Sep 11, 2026
yorickreum
force-pushed
the
windows-native-build
branch
2 times, most recently
from
September 15, 2026 09:15
09fb2f0 to
787c086
Compare
yorickreum
force-pushed
the
windows-native-build
branch
from
September 25, 2026 13:35
787c086 to
1ca19f9
Compare
stevengj
reviewed
Sep 26, 2026
stevengj
reviewed
Sep 26, 2026
| $(srcdir)/adjoint/utils.py | ||
|
|
||
| PY_PKG_FILES = $(INIT_PY) $(HL_IFACE) .libs/_meep.so | ||
| PY_PKG_FILES = $(INIT_PY) $(HL_IFACE) |
Collaborator
There was a problem hiding this comment.
So, this is replaced by the explicit cp below?
Contributor
Author
There was a problem hiding this comment.
Yes. The built name (.dll) and the importable name (.pyd) differ on Windows, so it needs its own cp with a rename. On Unix both are .so.
stevengj
reviewed
Sep 26, 2026
| // An absolute Windows path begins with a drive letter, e.g. "C:\dir\eps.h5"; | ||
| // that colon is part of the path, not the "file.h5:dataname" separator. | ||
| if (dataname == fname + 1 && isalpha((unsigned char)fname[0])) dataname = NULL; | ||
| #endif |
Collaborator
There was a problem hiding this comment.
I wonder if we should do
char *dataname = strstr(fname, ".h5:");
if (dataname) { *(dataname + 3) = 0; dataname += 4; }instead. That will handle the Windows case, and will also behave better on operating systems where a colon is a valid part of a filename.
(It assumes that the HDF5 file ends with .h5, which isn't strictly necessary but should be a near-universal practice?)
Contributor
Author
There was a problem hiding this comment.
Yeah. That sounds fair. I now split at the first .h5: or .hdf5:, so .hdf5 files still work, and dropped the #ifdef _WIN32.
Collaborator
|
Thanks for working on this, overall it looks very reasonable. |
added 2 commits
September 26, 2026 12:09
Apart from a colon in an epsilon-input-file path, none are reachable on Linux or macOS, so they have gone unnoticed; four are latent bugs rather than build breakage. Source: * output_directory.cpp: Windows mkdir() takes one argument, and its remove() fails on directories, so nftw() aborted and delete_directory() removed nothing at all. * meepgeom.cpp: epsilon-input-file was split at its last ':', so "C:\dir\eps.h5" became the filename "C" and the failed H5Fopen aborted. It is now split after a ".h5:" or ".hdf5:" extension, which also keeps colons in Unix paths part of the filename. * mympi.cpp: _GNU_SOURCE came after <cstdlib>, too late to declare vasprintf() on mingw-w64. * tests/h5test.cpp: POSIX sync() does not exist there, breaking the C++ test suite's compile. Build: * Windows DLLs may not contain undefined symbols; without -no-undefined libtool silently emits a static archive. * PYTHON_LIBS was referenced but never set. Empty is right on Unix, where modules take their symbols from the interpreter; on Windows they must link the Python library. Module suffixes (.so vs .pyd) are chosen per host too. * _mpb linked only libpympb, relying on transitive resolution Windows does not permit. Both modules use -avoid-version now, as no platform imports a versioned extension module. * sphere-quad.h's rule ignored $(EXEEXT). * TESTS_ENVIRONMENT built PYTHONPATH from $(abs_top_builddir): an MSYS "/c/..." path joined with ":", neither readable by native Python. * test_mpb.py passed a path as an re.sub() replacement, where backslashes are escapes. A native build also needs lt_cv_deplibs_check_method=pass_all; libctl, harminv, mpb and libGDSII need their own fixes.
Builds and tests Meep on windows-latest via MSYS2. No dependency needs patching: harminv is built static, MPB already carries -no-undefined, and the one libctl omits is supplied on the make command line. The reasoning behind the less obvious choices -- UCRT64 over MINGW64, pass_all, libctl from a release tarball, and vendoring the runtime DLLs beside _meep.pyd -- is in comments in the workflow.
yorickreum
force-pushed
the
windows-native-build
branch
from
September 26, 2026 10:10
1ca19f9 to
ff31889
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Turns out that not much needs to be adjusted to be able to build and run MEEP natively on Windows (with MYSY2 UCRT64)... All required changes are in the first commit, the second commit adds a Windows CI runner.
Addresses #385