Re: [tdf-discuss] Migrating LibreOffice Build System to Bazel

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