openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Lewis <>
Subject Re: [DISCUSSION] Build environment future
Date Tue, 05 Nov 2019 19:20:16 GMT
I'd like to see go away and switch to gmake at the top level. is bloated with a lot of stuff that we don't use and gets in
the way of efficient parallel builds.  Sometimes we don't have N modules
that we can build at the same time, so it would be nice to be able to
use the extra CPU cores to start more parallel compiles in the modules
that we are able to build.  Other times modules can be single-threaded,
and it would be nice to start building more modules.  This is possible
using gmake at the top level as well as the module level.

Generating the top-level Makefile with the module dependencies should be
fairly easy.  I think the big missing piece is the deliver stuff for the
non-gbuild modules.

On  5 Nov, Damjan Jovanovic wrote:
> 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/; 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 (
> 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 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 <> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message