On Thu, Jul 3, 2025 at 10:57 PM Peter Kovacs <peter.kov...@posteo.de> wrote:
> Hi Dave, Damjan, > Thanks for the quick replies. > > Am 03.07.2025 19:11 schrieb Damjan Jovanovic: > > 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. > I think we should avoid the back-porting effort. We want to catch up. > And should think about how we can minimize the effort. > > > > 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. > This sounds like Dave's suggestion. I prefer this route too. > However, it comes with 2 topics to consider. We still need trusted > builds, we can build a vanilla python and package it, > While this sounds nice, our build system is not made to bind external > binary dependencies. And this is my pain point. > If we go for an external binary, we need to make sure our build system > handles this. > > Or we build from source and go through the pain to have different SDK > setups. And deal with a binary build option later. > But if we have multiple dependencies where we need binary dependency > integration, it may maybe worth investigating a way to handle binary > dependencies in our build system. > > That should be very easy. Dmake scripts that build from source allow custom commands, which could unpack binaries and install them, with even less work. > > > > 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. > From what I know, Clang has support from Microsoft, and it is integrated > in Visual Studio 19 and later. > I would like to build with clang someday in order to get rid of Cygwin > on Windows. It would very simplify build setup on windows. > But we need a lot of changes for this and i would like to do this > somewhere later. > It's not the compiler that ties us to Cygwin, it's make. The only thing makefile rules can do is run shell commands, and for consistency, those are *nix commands on all systems (zip/unzip, tar, sed, tr, dozens more), provided by Cygwin on Windows. They're not provided by cmd.exe nor by PowerShell. Many newer build systems, including SCons and Meson, avoid this problem by running commands in Python instead of the shell.
