openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: [DISCUSSION] Build environment future
Date Tue, 05 Nov 2019 03:36:44 GMT
Hi

Ant already works for some Java modules, though at a module-only level. I
did get gbuild to extract dependency information from Ant, and build Ant
modules in the right order. For C++ though, I don't see how Ant is
possible. Even if we do get it to call the C++ compiler, it doesn't support
parallel builds. Also Ant is quite old, its build.xml file format wasn't
designed to be verifiable by an XML schema.

I should have some time for more AOO development in a week or so. I've been
stuck on porting the "config" build API to gbuild (which seems to be some
sort of API for XML configuration of UNO components, and schemas and XSLT
code to verify them at build time - main/solenv/inc/tg_config.mk); once
that's ported, 9 more modules should be portable to gbuild. That has been
particularly difficult, and it seems to affect post-build packaging too.

Another 8 modules relate to Windows. I'll have to setup up a fuller Windows
build environment for those, and I wonder if they need updating - several
of them use .NET 2.

It was quite encouraging to see that on Win64, several modules that didn't
build in dmake, started building once they were converted to gbuild.

In other news, I've been playing around with Wine, to try and cross-compile
the Windows version of AOO without Windows. I helped fix a Wine bug that
was crashing Cygwin scripts during installation and making the install take
hours (
https://source.winehq.org/git/wine.git/commit/2e53f8bccb65d112e5e341586c730094950fe6c3).
Cygwin installed nicely on Wine, bash builtin commands started working.
Then I ran into a bug where Cygwin expects user APCs to be called during
DLL loading, and Wine's DLL loading doesn't call any wait functions that
would trigger calling APCs, so a thread that would be created by an APC
doesn't get created, so fork() hangs waiting for that thread to suspend all
other threads and copy their memory to the child process (which is the only
way to fork() properly on Windows). Patching Cygwin to create that thread
directly (without using APCs) gets it further, fork() creates the child
process, but then fails an assertion and aborts because some data structure
in the child process is not at the expected address. If we can get a
working Windows build environment set up in Wine, we should hopefully
reduce build times for the Windows build from the current 5-8 hours, closer
to the 90 minutes it takes for the *nix build. AOO itself installed and
worked in Wine since OpenOffice.org version 1, so we should be able to both
build and test in Wine.

Of course, there is also the question of how well the Platform SDK and
other dependencies work on Wine. But I am quite optimistic. Cygwin is
unique in messing around with low-level operating system implementation
details. It even binary-patches some functions in NTDLL.DLL to speed up
getting the current working directory (which is apparently slow on Windows).



On Wed, Oct 30, 2019 at 7:25 AM Peter Kovacs <peter.kovacs@posteo.de> wrote:

> Hello Damjan and all
>
>
> I would like to re-discuss our current plan. Hoping to gain a common view.
>
> Current state is mostly we use gmake, there are still some difficult to
> migrate dmake projects. And we use Ant for java.
>
> The plan is not to stop at the dmake -> gmake conversion but to move on
> to scons, removing as much dependencies as we can. Right?
>
> I would like to set the target to build everything to Ant, removing as
> much dependencies we can.
>
>
> My arguments are mostly that Ant is supported by most when not all IDEs
> and I would really like to have an IDE as working environment, and my
> hope is that it is easier maybe to integrate an Ant build environment
> then a scons or gmake environment.
>
>  I think this would give us a better base then the plan above. So what
> was the arguments against Ant again?
>
>
> All the Best
>
> Peter
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message