Hi Neil,
Thank you very much for your thoughtful feedback.
I get the impression that a large part of the open source community is
converging on this build system and it
would be nice to be able to share the growing base of expertise with it.
I also agree that Meson has strong community momentum.
However, Bazel was designed around the principle of /“*One tool,
multiple languages.*”/
LibreOffice, being a multi-language project with complex dependency
management across C++, Java, Python, and Rust components, seems
structurally well suited for Bazel’s model.
This is especially relevant if we also consider the long-term goal of
maintaining both desktop and mobile versions under one unified build system.
So while community adoption is valuable, I believe */architectural
suitability/ *is even more important for LibreOffice’s scale.
I don’t know whether a new build system will improve the build times,
but I think it’s worth noting that the current build system is quite
slow even when there is nothing to build.
I agree — LibreOffice’s Makefiles are already quite sophisticated in how
they handle parallelism,
so I don’t expect major improvements in raw compilation speed either.
I wonder if it would make more sense to replace the legacy Perl scripts
with actual Python instead of a language from the build system. I think
this could be done incrementally and doesn’t depend on replacing the
entire build system.
I’m sorry if my previous message was misleading.
The goal is not simply to rewrite the existing scripts in Bazel syntax,
but *to simplify the fundamental structure of our build, from the gbuild
logic to the way modules are organized, in order to enhance long-term
maintainability.*
Simply porting Perl or awk scripts to Python would make them more
readable, but it would not address the underlying structural complexity
of the current system.
Another difficulty around changing the build system that might be worth
mentioning is that the current one is also partially exported to
extension developers as part of the SDK.
Thank you — that’s a very important point.
Fortunately, Bazel allows for *incremental adoption*, so we could
maintain compatibility with the existing Make-based SDK during a
transitional period.
A gradual, side-by-side migration strategy should make it possible to
replace components safely over time without breaking the developer
workflow.
Best regards,
Haruhiko Nishizaki
*
*
*
*
*
*
*
*
On 2025/10/13 15:51, Neil Roberts wrote:
jijinbei<[email protected]> writes:
I recently openedBug 168776
<https://bugs.documentfoundation.org/show_bug.cgi?id=168776> (https://bugs.documentfoundation.org/show_bug.cgi?id=168776
<https://bugs.documentfoundation.org/show_bug.cgi?id=168776>) to propose
migrating the LibreOffice build system from Make, autotools, and Perl to
*Bazel*.
If we’re going to consider migrating the build system I’d like to also
nominate Meson for consideration. I get the impression that a large part
of the open source community is converging on this build system and it
would be nice to be able to share the growing base of expertise with it.
Indeed several of the external dependencies of LibreOffice are using it
so I’m sure a lot of the LibreOffice devs are already familiar with it.
In my experience working on other projects that use it it always been a
positive experience.
*Incremental Builds:* Bazel can significantly reduce compilation
time compared to the current Make-based system.
I don’t know whether a new build system will improve the build times,
but I think it’s worth noting that the current build system is quite
slow even when there is nothing to build. On my old Mac if I change just
one file and build there is quite a noticeable delay before it even
starts compiling this one file. I imagine this is just the time needed
for Make to parse the thousands of non-trivial make files. I guess the
advantage of using something like Bazel or Meson is that the generated
build files can be optimized and would presumably take less time to
parse. This would probably improve the development process for a lot of
people if the write-build cycle time was reduced.
*Modern Build Language:* Legacy Perl scripts could be replaced by
the modern, Python-like Starlark language.
I wonder if it would make more sense to replace the legacy Perl scripts
with actual Python instead of a language from the build system. I think
this could be done incrementally and doesn’t depend on replacing the
entire build system. It might even be nice to do as mentoring tasks that
are slightly harder than “easy hack”.
Another difficulty around changing the build system that might be worth
mentioning is that the current one is also partially exported to
extension developers as part of the SDK. So if we wanted to avoid
breaking the builds for extensions we would presumably have to continue
maintaining the make files that are installed in the SDK.
Regards,
– Neil
