Windows build: Support for python 3.8 and up

[mhertz]

With the new add_dll_directory() to correctly load the runtime dll

[mhertz]

For context, this is patch used by gvsbuild to build without failing on py3.8 and up, and I just added an improvement regarding workarounding possibility of trailing semicolon in PATH env-var I borrowed from gvsbuild dev used elsewhere, as for me and him fixed usage from pyinstaller freezed exe.

Initially requested inclusion in gvsbuild, but was suggested good idea of getting included upstream instead. Thanks in advance.

[ylatuya]

I think it shouldn't be pycairo's responsibility to add directories to the search path as it has limited knowledge about how the consumer application has been packaged or built. Cairo's shared library can have different filenames, depending on how it was built and the toolchain used for example. Your patch would not work with GStreamer's build, where the shareed llibrary can be named cairo-2.dll or libcairo-2.dll when it's built with MinGW for example.

The application importing pycairo should have enough knowledge to set the correct search paths for DLL's, either because it bundles the dependencies in a known path or using a similar logic as the one you implemented knowing how the user was instructed to install the dependencies required by the application.

[lazka]

I agree with @ylatuya

[stuaxo]

I think one case is slightly different -
There is a use case for a WHL with an internal cairo dll - for the simple case of apps that want to draw using cairo and output to PNG, SVG or PDF and have no GUI.

There could be an API to opt into using the internally supplied dll.

[lazka]

If the wheel ships a DLL it should by default add the path, yeah, but in our case the the DLL is in the same directory as the .pyd file which is looked up by default anyway, so no action needed.

https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew -> "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"

[mhertz]

Thanks for comments, and please deem if/when need closing yourself, as honestly don't like myself judging that.

Anyway, of-course these are valid points, and frankly I'm not very much in the know by all of this, but just thought that as atleast in gvsbuild doesn't build without failing(without patching added, I mean, hence initially added), because can not find needed dll, when on py3.8+, and then just slight extra pyinstaller related fix on-top.

Regardless this is now merged by gvsbuild, so not that big deal, but just fit better upstream as per the sentiment of gvsbuild dev as mentioned.

Thanks again, appreciate your work and thoughts :)

[lazka]

hm, good point, pygobject will import pycairo to find its header files during build, but it wont know where the DLL is either, so importing would fail :/

[lazka]

Fixed in pygobject 3.42.2 https://pygobject.readthedocs.io/en/latest/changelog.html#id1

It will no longer try/require to import pycairo during the build.