The wheel builder then copies the Python modules (*.py) and extension modules (*.dll) from the Python library directory (build/vtkmodules/) to a new directory:
Which is then copied to build/build/bdist.cygwin-3.3.4-x86_64 and zipped. As a result, I am lacking the export and import libraries that normally ship with the wheel. If you download an official VTK wheel from PyPI you see that it includes, among other things, /wheel/{*.py, vtk*cpython*so, libvtk*.so*}. This means my wheel is unusable.
The export libraries are packaged with the import libraries in what should be, one my side, build/build/lib.cygwin-3.3.4-x86_64-3.8/vtkmodules/
The wheel builder copies the python libraries to the import library directory rather than the new *cpython* python wheel directory.
What flags can I use to build my wheel so I get a wheel like an official wheel without missing files? I looked at the GitLab CI CMake files but nothing stood out.
P.S.
Here is the patch I used to build VTK 9.1 (current master) on Cygwin. I built it with the following flags (some required):
Note that Cygwin support is best-effort and generally maintained by contributors as it is not an actively tested nor supported platform.
The final patch below allows VTK to compile on Cygwin and is my best effort at contributing a working Cygwin build system. Some of the changes are hacky, some have already been integrated upstream into the ThirdParty libraries, some are great, and some… well, let’s just say I don’t know how the VTK maintainers didn’t notice certain build flag combinations probably wouldn’t compile even on Linux (conflict with X/X.h). Also some of the customized ThirdParty libraries are in horrible state regarding preprocessor macros, especially loguru and netcdf, but loguru upstream is much better. The patch solves the issues in my first post and fixes DLL loading for the Python VTK modules. VTK takes about a day to compile so as far as I’m concerned it’s finished.
The .dll.a files shouldn’t be required in the wheel. We don’t ship .lib files in the official wheels. What do you need them for?
I don’t need the .dll.a nor the .lib files but I need all the .dll files. For example, the official Linux wheel ships with VTK-Python modules such as vtkIOAsynchronous.cpython-38-x86_64-linux-gnu.so as well as VTK modules such as libvtkIOAsynchronous-9.1.so and libvtkfreetype-9.1.so. I would need vtkIOAsynchronous.cpython-38-x86_64-cygwin.dll as well as cygvtkIOAsynchronous.dll and cygvtkfreetype.dll, but I only get vtkIOAsynchronous.cpython-38-x86_64-cygwin.dll (and other VTK-Python modules).
Just found out the black magic used to get Cygwin to load the VTK DLL dependencies prevents Python from loading most extension modules. This means VTK has to be imported last. Since I can’t figure a workaround, no merge request.
Specifically, changing SetDefaultDllDirectories prevents random Cygwin DLLs from loading, but in combination with AddDllDirectory is required to load dependencies of VTK DLLs.
This sounds like an issue to raise with Python upstream. Personally, the idea behind os.add_dll_directory is nice, but I think the cure is worse than the disease in this case (because of the way the platform works).
Only the system paths, the directory containing the DLL or PYD file, and directories added with add_dll_directory() are searched for load-time dependencies.
Anyway I’ve managed to work around the Cygwin issue. Can gitlab import merges from github?
Yes, in general. Wheels are a degenerate case. It’d still be needed in the general case because any wheel wanting to load VTK libraries would need this os.add_dll_directory() (unless they provide their own copy which is…dangerous).
Not to my knowledge. But to facilitate feedback, please contribute on gitlab directly. You can login using your github account.