https://bugs.documentfoundation.org/show_bug.cgi?id=168776
Bug ID: 168776
Summary: Switch build system to bazel
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
This proposal is related to Bug 113121.
Migrating the LibreOffice build system from Make, autotools and Perl to Bazel
could bring several benefits and simplifications.
Advantages expected from Bazel migration:
- Incremental Build: Significantly reduces compilation time compared to the
current Make system.
- Simplified File Structure: As of 2025-10-10, LibreOffice has about 2,581
Makefiles. With Bazel, this could be reduced to around 150 `BUILD.bazel` files
(one per module).
- Unified Testing: Using `bazel test` would remove the need to create a
separate Makefile for each unit test.
- Modern, Readable Build Language: Replace legacy Perl scripts with the
Python-like Starlark language.
- Refactoring Opportunity: Current complex integrations among autotools,
gbuild, and Perl scripts make refactoring of old OpenOffice-era code difficult.
- Module Management: Bazel’s `MODULE.bazel` and `http_archive` can consolidate
external dependencies under a single configuration file, instead of the
`external/` directory clutter.
- Cross-Platform Builds: `select()` expressions in Bazel can cleanly handle
platform-specific build options.
I understand that such a migration would inevitably cause disruption and
require a significant adaptation period for contributors and CI infrastructure.
However, if LibreOffice continues to grow in complexity and scale, modernizing
the build system will become increasingly important for maintainability,
reproducibility, and onboarding new developers.
In short, Bazel could modernize the LibreOffice build process, reduce
maintenance burden, and improve readability and reproducibility.
I’d like to ask whether there has been any previous attempt or internal
discussion on this topic, and whether a partial migration (e.g., per module)
could be acceptable.
Thanks,
Haruhiko Nishizaki
--
You are receiving this mail because:
You are the assignee for the bug.
