Hi Christian,Thank you very much for taking the time to write such a detailed and thoughtful response.
Those are always bold claims that are easy to make and that might be true for small projects, but most of the time that falls flat the more files a buildsystem needs to take into account, wouldn't surprise me if some would get exponentially slower...
I completely agree — I’m not expecting any dramatic compile-time speedups.What I find valuable about Bazel is that /caching and dependency tracking are built into the system by default/.
Yes, I understand this is mostly an organizational convention in LibreOffice. However, one advantage of Bazel is that it integrates testing into the build model. Each library or module can declare its own test targets directly, so developers can follow the conventions of the language or library itself rather than LibreOffice-specific ones. This could help reduce the number of LibreOffice-specific build rules developers need to learn, making the system simpler and easier to work with.The number of makefiles is not a requirement, but rather organizational/convention that helps to logically group stuff. The makefiles could be combined in gnu make as well, but whether that will help with maintainability/readability is a completely different topic.
That’s fair — and I think losing some legacy functionality is acceptable if it leads to a simpler and more maintainable structure. In my view, gbuild has become so complex that almost no one fully understands its internals anymore. Ultimately, my goal would be to replace all the autoconf, shell, and make layers with Bazel over time.conversion of some perl scripts to python already caused loss of functionality and regressions, and python is surprisingly stubborn when it comes to unicode and behaviour on different operating systems, adding another language into the mix might not be very helpful.
I fail to see how the build system has an impact on code refactoring/how a different build system would help with that.
Currently, the gbuild layers and the complex flag logic in|configure.ac| are deeply intertwined. It’s often hard to understand which libraries depend on which, directly from the Makefiles. For instance, there have been discussions (e.g., tdf#39445, tdf#63154) about removing the|tools| module, but isn't the reason this has proven difficult that*importing* external libraries like|chore| or|nlohmann/json| is not straightforward under the current setup?
That's a gross oversimplification, those external dependencies are built and shipped along with LibreOffice, so bazel would also need to configure/compile them.
That’s true, but Bazel can already handle this kind of workflow using rules_foreign_cc(https://bazel-contrib.github.io/rules_foreign_cc/) <https://github.com/bazel-contrib/rules_foreign_cc> which allows integrating libraries built with Make, CMake, or Meson relatively easily. I expect this could simplify external integration rather than complicate it.
There's little maintenance burden, if you compare what changes are done to the build system vs how many are done to the code, the changes to the build system files is usually just adding another file to an existing list, or copying a block for another module, not much in working on the build system.
Even if editing the build system often means “just adding one line to a list,” the overall dependency structure still remains something of a black box — is there really anyone who fully understands how all of it fits together?
Not sure how a different build system would help with reproducibility/what kind reproducible you mean here.
Bazel isolates builds inside sandboxes and treats each build action as a pure function, which prevents side effects and ensures the same inputs always produce the same outputs. In contrast, Make-based builds depend heavily on environment variables, PATH settings, and the OS configuration. That’s the level of /reproducibility/ I’m referring to — deterministic builds, identical across machines.
A minimum viable demo should show how to deal with the configure options, should work on linux, macOS and Windows (and not a handwavy "can be easily adapted to…" style), should show how externals are integrated, should show how the non-compilation stuff like packaging extensions or help should work. But that is just me personally speaking.
I’m currently experimenting with a minimal Bazel-based build on Linux to see whether a complete migration is technically feasible. It will take time, but once it’s working I’d like to share the results for discussion.
On 2025/10/13 20:06, Christian Lohmaier wrote:
Hi *, On Sun, Oct 12, 2025 at 7:21 PM jijinbei<hallucigenia2002@gmail.com> wrote:I recently opened Bug 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.Those are always bold claims that are easy to make and that might be true for small projects, but most of the time that falls flat the more files a buildsystem needs to take into account, wouldn't surprise me if some would get exponentially slower...*Simplified File Structure:* As of October 2025, LibreOffice contains about 2,581 Makefiles. This could be reduced to around 150 |BUILD.bazel| files (roughly one per module).The number of makefiles is not a requirement, but rather organizational/convention that helps to logically group stuff. The makefiles could be combined in gnu make as well, but whether that will help with maintainability/readability is a completely different topic.*Unified Testing:* |bazel test| would remove the need for separate Makefiles for unit tests.See above, the makefiles aren't separate for technical reasons.*Modern Build Language:* Legacy Perl scripts could be replaced by the modern, Python-like Starlark language.conversion of some perl scripts to python already caused loss of functionality and regressions, and python is surprisingly stubborn when it comes to unicode and behaviour on different operating systems, adding another language into the mix might not be very helpful.*Refactoring Opportunity:* The current integration among autotools, gbuild, and Perl scripts makes refactoring legacy OpenOffice-era code difficult.I fail to see how the build system has an impact on code refactoring/how a different build system would help with that.*Module Management:* Bazel’s |MODULE.bazel| and |http_archive| features can consolidate external dependencies into a single configuration file, rather than the scattered |external/| directory.That's a gross oversimplification, those external dependencies are built and shipped along with LibreOffice, so bazel would also need to configure/compile them.*Cross-Platform Builds:* |select()| expressions can cleanly handle platform-specific build options.That is what all build systems claim, but when taken to the test the devil is in the details. Let alone cross-platform configuration, many don't even have an adequate replacement for configure and the vast amount of switches we have.In short, Bazel could modernize LibreOffice’s build process, reduce maintenance burden,There's little maintenance burden, if you compare what changes are done to the build system vs how many are done to the code, the changes to the build system files is usually just adding another file to an existing list, or copying a block for another module, not much in working on the build system.and improve reproducibility.Not sure how a different build system would help with reproducibility/what kind reproducible you mean here.I’d like to ask whether there have been any previous attempts or internal discussions on this topic,Not aware of anything specifically for basel, but the question of a build system change comes up from time to time. But I'm highly sceptical when the build system has a concept of something like a library or cc binary already, that usually means it is a bad fit for LibreOffice and its many types of build tasks. Tasks that are not only compiling c code.and whether a *partial or per-module migration* could be considered as a starting point.Guess a per-module approach is the only viable way due to the scale of the project if done manually. But a better way would be to have an automatic conversion of the make rules to the other build system. Our makefiles make heavy use of macros/templates, so that can be an advantage/that is also what our gbuild-to-ide system uses in part. A minimum viable demo should show how to deal with the configure options, should work on linux, macOS and Windows (and not a handwavy "can be easily adapted to…" style), should show how externals are integrated, should show how the non-compilation stuff like packaging extensions or help should work. But that is just me personally speaking. I'm highly sceptical of those tools... ciao Christian
-- To unsubscribe e-mail to: discuss+unsubscribe@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/discuss/ Privacy Policy: https://www.documentfoundation.org/privacy