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.
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.
Regards
Damjan
Cheers
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
