Thank you for your thoughtful reply.
The current system already does builds incrementally.
That’s true.
However, Bazel provides a built-in caching mechanism that makes
incremental builds much more effective by default.
I think the wording should be "legacy Perl and awk scripts /have to
be/ replaced" and this is the same requirement as for Meson.
I may have caused a misunderstanding here — *my proposal is not about
simply /replacing/ Perl or awk, but rather /rewriting/ the entire logic
into a cleaner and more maintainable form.*
Even if we move from Perl or awk to Python, if we retain the same
complex gbuild architecture, then the migration loses much of its purpose.
The goal is to simplify and clarify the build structure itself, not just
change the scripting language.
Have you evaluated Meson against Bazel for LibreOffice?
I have not conducted a full evaluation of Meson versus Bazel
specifically for LibreOffice yet.
My initial reason for suggesting Bazel was mainly based on its design
features and long-term scalability, including:
* platform(), toolchain(), and select() for abstracting platform
differences across Windows, Linux, and macOS
* Proven scalability for large, multi-language monorepos and
distributed builds
* Built-in support for mobile platforms (Android, iOS)
There is inertia in continuing the build system migration because the
current autoconf-based system is one of the cleanest implementations
you will find in any project, works fine and the maintenance is not
really a burden. So the benefits of moving to something else are not
that significant.
I fully agree that the current autoconf-based system is extremely
well-engineered and reliable — it’s impressive that it continues to work
consistently across so many environments with |autogen.sh| and |make|.
However, looking forward, I think developer /accessibility and
maintainability/ will become increasingly important if LibreOffice wants
to remain competitive with modern alternatives such as ONLYOFFICE.
At the moment:
* The build scripts are complex and difficult for new contributors to
modify safely.
* Cross-build configurations are scattered and not always intuitive.
With Bazel, we could achieve:
* A unified, declarative configuration that spans multiple platforms
and languages
* Hermetic (fully reproducible) builds with isolated environment
This would reduce the long-term maintenance cost and make the build
system more approachable for new contributors and CI pipelines alike.
Thank you again for your thoughtful input.
Best regards,
Haruhiko Nishizaki
On 2025/10/13 15:59, Ilmari Lauhakangas wrote:
On 10/13/25 05:29, jijinbei wrote:
Dear LibreOffice developers and contributors,
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*.
In the discussion there, I was advised to bring this topic to this
mailing list for broader feedback and discussion.
I believe such a migration could bring several benefits and
simplifications, including:
*
*Incremental Builds:* Bazel can significantly reduce compilation
time compared to the current Make-based system.
The current system already does builds incrementally.
*Modern Build Language:* Legacy Perl scripts could be replaced by
the modern, Python-like Starlark language.
I think the wording should be "legacy Perl and awk scripts *have to
be* replaced" and this is the same requirement as for Meson.
Have you evaluated Meson against Bazel for LibreOffice? There has
already been a significant amount of work done in making LibreOffice
build on Meson and this included rewriting many Perl scripts in
Python. One part of this was creating a WiX-based Windows installer
(not yet in production).
There is inertia in continuing the build system migration because the
current autoconf-based system is one of the cleanest implementations
you will find in any project, works fine and the maintenance is not
really a burden. So the benefits of moving to something else are not
that significant.
Support was added recently for building HarfBuzz with Meson and the
long process revealed some problematic things and assumptions in Meson
itself, mainly on Windows if I recall correctly. Probably there would
be an equal amount of surprising problems in Bazel.
Ilmari
