https://bugs.documentfoundation.org/show_bug.cgi?id=168776
--- Comment #3 from Eyal Rozenberg <[email protected]> --- (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/ -- You are receiving this mail because: You are the assignee for the bug.
