You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Peter Kovacs <pe...@posteo.de> on 2025/07/03 15:59:54 UTC

Python 3 build on windows

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Python 3 build on windows

Posted by Dave Fisher <wa...@apache.org>.

> On Jul 3, 2025, at 8:59 AM, Peter Kovacs <pe...@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?

IMO - Always using a system provided Python3 is a good way to go, even better would be one that sets up a venv to isolates any requirements. This moves the setup work to installation on all of our environments to installation scripts.

You can very likely ask an AI how to do this as it’s very common.

Best,
Dave

> 
> Thanks for your oppinions
> All the best
> Peter
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Python 3 build on windows

Posted by Damjan Jovanovic <da...@apache.org>.
On Sat, Jul 5, 2025 at 10:27 AM Arrigo Marchiori <ar...@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 <pe...@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 <pe...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Regards
Damjan

Re: Python 3 build on windows

Posted by Dave Fisher <wa...@apache.org>.
Hi -

I want to respond to this.

> On Jul 5, 2025, at 1:26 AM, Arrigo Marchiori <ar...@apache.org> wrote:
> 
> External packages could also raise the bar of system requirements:
> would they still work on older Linux or Macos releases?

Right now we support what are now very old versions of macOS, versions where you can no longer update your browser of choice. For 4.2.0 we should discuss having a more modern minimum OS version.

I’m not sure which version should be the minimum, but if pick the right one we could solve the GateKeeper problem.

Best,
Dave

Re: Python 3 build on windows

Posted by Peter Kovacs <pe...@posteo.de>.

Am 05.07.2025 10:26 schrieb Arrigo Marchiori:
> 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 <pe...@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 <pe...@posteo.de>
>> > > wrote:
>> > > 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.
the python patches we use change types of variables within python. I 
have doubts that this helps in debugging.
We should not touch external libs except patching old versions properly 
if we believe they are still used.
> 
> External packages could also raise the bar of system requirements:
> would they still work on older Linux or Macos releases?
If we can keep the old sdk workable, by decoupling everything we would 
not have the issue. I mean we have a fixed feature set. we would not add 
something really.
Where we offer binaries that is then still our choice.
> 
>> > > 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,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Python 3 build on windows

Posted by Arrigo Marchiori <ar...@apache.org>.
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 <pe...@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 <pe...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Python 3 build on windows

Posted by Damjan Jovanovic <da...@apache.org>.
On Thu, Jul 3, 2025 at 10:57 PM Peter Kovacs <pe...@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 <pe...@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.

Re: Python 3 build on windows

Posted by Peter Kovacs <pe...@posteo.de>.
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 <pe...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Python 3 build on windows

Posted by Damjan Jovanovic <da...@apache.org>.
On Thu, Jul 3, 2025 at 6:02 PM Peter Kovacs <pe...@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