Hello All, replying to the whole thread here.
On Fri, Jul 04, 2025 at 06:21:48PM +0200, Damjan Jovanovic wrote: > 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. While I agree that back-porting is not sustainable, it is the best way we currently have for quickly integrating newer code. It's feasible with C, but it could get _very_ difficult (if not impossible) with C++, as Damjan noted. Let us consider it the ``last resort'' for small, urgent tasks. > > > 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. FWIW I do not like the idea of integrating external binary packages, for the reasons Damjan mentioned: no possibilities to patch them, less and less x86 builds, hard debugging. External packages could also raise the bar of system requirements: would they still work on older Linux or Macos releases? > > > 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. In fact, for the long run, I thought that a migration to SCons could be the best choice. Not only we would lose some more dependency on Cygwin, but most of all we would get integration of newer compilers ``for free''. The last time I looked into SCons, there were tens (a hundred?) of modules still needing to be ported to SCons, plus some other tasks that seemed to be ``philosophycally'' difficult with SCons, such as unpacking & building an external package with its own configure and make scripts. I personally would also like to keep DMake and GBuild and work on building with Mingw compilers, but it's just because I like to work with Unix-like tools. I am not sure this would be the best choice in to ensure longest-term sustainability. I suggest we define together ``the way to go'' and then concentrate our efforts in that direction. Dispersion is something we cannot afford, at the moment. My current vote would be for SCons, but I would like to hear Damjan's opinion on that. Best regards, -- Arrigo --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
