On Thu, Jul 3, 2025 at 6:02 PM Peter Kovacs <peter.kov...@posteo.de> wrote:
> Hi all, > > i am replacing python 2 with python 3. And i have currently the issue > that an actuall windows python 3 Version needs Microsoft Visual Studio > 2017, which is way newer of what we need on windows. > > I struggle a bit how to deal with this requirement. It would create > additional complexity if we build python 3 during the build. > If we remove the python 3 build from our build process we need to add > python3 check to config step and we need to remove the python module. > And it opens the question how we do add python to a windows installer. > > Any insights or Ideas how to deal with it? Should i keep the build of > python in our build environment? > > Thanks for your oppinions > All the best > Peter > > I have the same problem to solve with the ICU upgrade, and I see the following options: 1. Patch the dependency to build with our older MSVC. We already do that for some dependencies, eg. nss. The effort would grow with the amount of code to patch. Also in nss we simply move C variable declarations to the beginning of the function, but eg. ICU needs a newer C++ version, and downgrading the C++ version would require far too many changes. 2. Link to a binary build of the dependency instead of compiling from source. This is easier than building from source, and cuts down our build time, but limits us to what upstream (or another trusted source) provides. Also upstream projects are increasingly supplying amd64 binaries only, x86 not so much, and since at present our Windows build is x86 only that would be a problem. And this would only work for dependencies that don't need to be patched, as we can't apply patches to binaries. Also build flags would differ, eg. in a debug build the dependency wouldn't have debug symbols. 3. Support another compiler, and allow each module to build with a compiler of its choice. mingw-w64 and Clang are both free open-source compilers that can build Windows binaries, and (hopefully?) don't limit us to Windows 10+ only like newer MSVC would, or to C89/C++98 only like the current MSVC does. This gives us the greatest flexibility, as each module could compile with its own choice of compiler, dependencies could be patched if needed, we could use compiler and linker flags consistent with the rest of the build so dependencies get debug symbols in debug builds. This is my preferred option, but I haven't had time to investigate it yet. Regards Damjan
