Contributions upstream?

[zooba]

This is some very impressive work here! (Mainly looking at the Windows script, since that's my area ;) )

Obviously what you've got works great, but I wanted to let you know that I'm more than happy to accept changes to the Windows build files upstream to help make this easier - static builds in particular. I doubt you've had to do too much to keep up with changes, since we don't make so many, but anything you'd rather invoke as a build option rather than modifying files is certainly on the table.

[indygreg]

Hi @zooba! I'm familiar with your work upstream :)

Upstreaming build system changes is perpetually on my todo list. There are some legit bug fixes in there, especially around some of the lesser used build system features (like cross compiling). There are also some changes that I anticipate would be controversial.

Windows static builds is one of those features that I assumed upstream wouldn't be interested in due to its scope/complexity and ongoing support costs for upstream.

My overall experience with the Windows static builds has not been great. Since those builds break ABI compatibility due to how Windows handles symbol naming for imported/exported symbols, you can't leverage binary wheels on PyPI and this opens the hornets nest of people having to compile extensions from source. You can imagine what a pain this is for some packages! There is also some runtime wonkiness, such as with the OpenSSL library not behaving correctly - but this may be a bug with how I'm compiling it or assumptions that CPython makes about how OpenSSL is built on Windows.

I naively assumed that if upstream took patches for Windows static, then that would create an expectation of some kind of support. People would likely want official target support in packaging tools like pip. And binary wheel support on PyPI. And...

Don't get me wrong, if upstream is willing to take patches from python-build-standalone, I'm happy to contribute if I have time. But, selfishly, I don't want to get bogged down in all the politics around convincing people to take them. If you or someone else spells out which functionality/patches would be acceptable upstream, I can probably put in the work to submit them. That does save me time in the long run as it reduces the burden on maintaining this project. Especially for some of the more complex patches, like Windows static and better cross-compiling support. Let me know! I'm also happy to drop on a call to discuss synchronously, if preferred.

[zooba]

Yeah, I'm familiar with all the limitations due to the dependencies on the DLL (if you really wanted you could probably create a forwarding DLL like python3.dll that points back at the executable, but that's just an idea with no certainty as to whether it works).

I'm happy to take on the politics. Fundamentally, there's a difference between having patches for things and declaring them supported - for example, we've had changes for a few releases now to enable ARM/ARM64 builds, but no implication of support (and I've been resisting making releases because it would imply support, though I'm going to be pushing towards ARM64 releases for 3.11).

Enabling new kinds of builds is fine, provided someone cares enough to use it (i.e. you) and a core dev cares enough to review and merge it (i.e. me). Provided it doesn't break or impact the builds we do support, it won't be an issue. All I'd say is try and submit one change at a time, rather than everything at once, just to chip away at it, and probably focus on the build.bat/pcbuild.proj interface rather than the solution file at first (just because I know how drastic it can be to get Visual Studio to handle this kind of option...)