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 should try Developer mailing list see https://wiki.documentfoundation.org/QA/BugReport#Not_all_issues_go_to_Bugzilla
thanks
(In reply to Haruhiko Nishizaki from comment #0) > - Incremental Build: Significantly reduces compilation time compared to the > current Make system. This is not specific to Bazel. In fact, it is possible with Make and autotools, and IIANM that is already the case to some extent. > - 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). One can reduce the number of Makefile's, if that's the target metric. But I don't see that some kind of build-info-file for every few folders is a bad idea, compared to packing those all together into smaller larger files. > - Unified Testing: Using `bazel test` would remove the need to create a > separate Makefile for each unit test. You don't need Bazel for that; nor do you have to have a separate Makefile for each unit test. > - Modern, Readable Build Language: Replace legacy Perl scripts with the > Python-like Starlark language. Actually, if it were a choice between some esoteric niche language and using perl, then naturally perl would be the winner. > - Refactoring Opportunity: Current complex integrations among autotools, > gbuild, and Perl scripts make refactoring of old OpenOffice-era code > difficult. This presents a detriment as a benefit. Plus, this too does not have much to do with bazel. > - Module Management: Bazel’s `MODULE.bazel` and `http_archive` can > consolidate external dependencies under a single configuration file, instead > of the `external/` directory clutter. Again, putting everything in a single configuration file is very often not a good idea and should not in itself be a goal. Moreover - those directories have various patches and possibly directory-specific logic. What would Bazel offer which removes this clutter? > - Cross-Platform Builds: `select()` expressions in Bazel can cleanly handle > platform-specific build options. Cross-platform and platform-specific are different things. Please explain why Bazel would be useful here - over what we do with Make right now, and over other build system generators like CMake or meson. > 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. Well LibreOffice should not grow in scale - I hope. As for complexity, some people are very much into building LibreOffice for use also as a web app or a mobile app, so that would increase complexity. I would actually say that regardless of those considerations, it's better if we could have less bespoke mechanisms, specifically for building, and forego bespoke logic in favor of what's more customary elsewhere. Still, you would have to make an argument in favor of Bazel relative to other build systems; and in fact - the moder, maintainable, reproducible, easy-for-onboarding choice seems _not_ to be Bazel. here's a discussion thread about bazel as an alternative to other build systems, which I feel is varigated enough to reflect most (?) opinions on the matter: https://www.reddit.com/r/cpp/comments/192jeuc/why_use_bazel_or_buck_instead_of_cmake_xmake/
for reference : https://lists.freedesktop.org/archives/libreoffice/2025-October/093870.html