openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <>
Subject Re: Thoughts on a new build system for AOO
Date Sat, 06 Feb 2016 07:11:30 GMT
On Fri, Feb 5, 2016 at 9:38 PM, Pedro Giffuni <> wrote:

> Hi Damjan and others;
> Indeed a new build system is very desirable but it is difficult to
> choose one. I agree that choosing one which we already have a need
> for in dependencies is wise.
> FWIW, I looked into some of the options myself:
> - Google's Bazel looked very promising:
> But it lacks support for Windows at this time.
It does look promising. All these next-generation build systems are
similar. Bazel, SCons and gbuild are all based on the idea of globally
visible dependencies between individual files. Bazel and SCons both use MD5
sums instead of timestamps to detect changes, and can do heavy caching
(like ccache for C/C++, but for all files). However the lack of Windows
support for Bazel is a showstopper.

> - CMake has been chosen by LLVM, and by a bunch of projects that need
> to be built cross platform. There was an aborted attempt for OOo:
> CMake, I understand, has been evolving a lot though.
CMake could be useful because it can cross-compile, but it implements
building by delegating to native tools on each platform, such as GNU make
on *nix, so it still suffers from the recursive make problem, and always
will (
The recursive make problem is the reason we have unstable builds and poor
parallelization. They say their Ninja backend doesn't suffer from it though.

Also guess what gbuild's horrible syntax is based on? CMake's syntax! CMake
is slightly easier to read though.

> - FreeBSD and NetBSD share a powerful bsd make utility. FreeBSD
> is still in the adoption process, and I can't say at this time
> how it compares with gbuild:
AFAIK all make utilities suffer from the recursive make problem, the only
way gbuild didn't is by using the eval feature in GNU make, and it still
left a lot to be desired.

> I haven't looked at scons and I am not objecting to it. Certainly
> anything is better than Dmake. My only comments, referring to
> Python, are:
> - We have somewhat of a chicken and egg problem now with Python as
> the build system is making it difficult to update our copy to
> something like 2.7.11 that supports newer Windows compilers.
Please elaborate.

> - One thing I would like to see at some stage is the possibility of
> using native windows tools like IronPython and Strawberry Perl
> instead of the cygwin stuff.
> Pedro.

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