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 <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:
> > 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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
