Hi *, On Sun, Oct 12, 2025 at 7:21 PM jijinbei <[email protected]> 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: [email protected] 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
