On Sat, Jul 5, 2025 at 10:27 AM Arrigo Marchiori <ard...@apache.org> wrote:
> 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''. > Yes, that would be wonderful. > > 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. Building external packages in SCons is working now, including applying patches to source, for both boost and ucpp. > 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. > > There are still a number of issues we need to solve before SCons becomes viable. Today I took the time to investigate and fix one of them, where paths of the '#/...' form were sometimes not expanding, and it turned out you have to either wrap them in the File() object, or convert them with env.GetBuildPath(). This fixed delivery issues with boost and sal. Next I need to investigate how dependencies work, because modules needing boost sometimes start building before boost is delivered, causing failures because they end up using the system boost headers which are of an incompatible version. You'll notice however, that in SCons I already solved 2 problems we haven't solved in gbuild: building external dependencies (boost, ucpp), and building modules which haven't been ported to gbuild because they do a lot of custom building (sal). These changes were made in a private experimental branch that I haven't pushed anywhere. > Best regards, > -- > Arrigo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > Regards Damjan
