Hi *,
On Mon, Oct 13, 2025 at 8:07 PM jijinbei<hallucigenia2002@gmail.com> wrote:
[…]
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.
As I have no insight on how that works, I'll just have to take your
word for it :-)
[structure of buildsystem files]
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.
We have various types of tests: cppunit, junit, python/UI… and most
are integration-style ones testing multiple components at once, so
that integration might not help much, we'd still have our testing
phases after the build is complete...
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.
I kinda doubt that this would be as easy in such a complex project
like ours that is using multiple components from different sources,
different build styles, etc.
[rewriting scripts just for the sake of rewriting has its risks]
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.
gbuild didn't really change since the first migration, so rather it
would be it never had been simplified after the transition phase when
there was a need for some workarounds when two buildsystems were used
at once. I agree that it can appear complicated when you let the macro
calls confuse you, but when you realize that these are mostly just
fancy placeholder replacements/path assembly operations it is way less
scary... But of course I'm biased since it is familiar, it already was
proven to work.
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?
Still even with these examples that are normal code refactorings that
don't even touch the build system since that is such old stuff. Also
absolutely cannot follow why removal of just old code/replacing it by
current code would imply that adding other external libraries would be
hard or not straightforward?
No idea what chore library is, and I'm not aware of someone wanting to
add a json library and not knowing where to start. When adding some
new dependency then it is more a question whether that external
library is available on all supported systems, is
maintained/stable/mature or not and of course whether it does
something we need and has a compatible license and what build system
that new thing uses.
As for what requires what, that's covered by the various
gb_<TargetType>_use_<dependencyType> macros, e.g.
gb_Library_use_libraries to set dependency on other built library or
gb_StaticLibrary_use_unpacked when it is enough that the archive of an
external is unpacked, so it is reflected in the makefiles, and
ultimately the complex logic in configure.ac is just complex because
there's so many different combinations of switches that are
intertwined, the logic would just be as complex in any other
configuration method (or that method would allow invalid combinations
or not support all combinations) - the end result/what the build then
basically is a simple BUILD_TYPE variable with the modules to build,
along with variables containing the compile/link flags for externals
along with some ENABLE_<FOO> for stuff that's finer than module level
– again any system that would support the current combination of
configure switches would have to reflect that in a similar fashion.
Just the option for e.g. linux distribtions to compile against their
system versions of external libraries vs compiling and shipping that
external library is really most of that complexity (and is something
that absolutely must be still possible)
[LO's externals are more than just build dependencies or a binary you grab from a repo]
That’s true, but Bazel can already handle this kind of workflow using
rules_foreign_cc(https://bazel-contrib.github.io/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.
Well, see above, it is not simply stating to always do that, but only
do that if condition XY, otherwise use the system version...
Also we very frequently require some patches to be applied to fix
bugs/adapt for dependencies, etc. And that is already something that
"shiny-new-thing" style buildsystems don't expect to do. Also
sometimes we ignore the external tool's buildsystem and use our own
makefiles, etc.
[most devs never need to touch the buildsystem, except for adding a line or copying an existing
snippet]
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?
Would there be anyone who would understand that in bazel? I don't know
bazel and I was looking for some more complex examples, but just
couldn't find anything even remotely comparable.
Even the mini-graph of module dependencies is already complex
https://wiki.documentfoundation.org/Development/Build_System compared
to whatever I saw in my search from an example, but that is peanuts if
you go in more detail, so one cannot reasonably expect someone to know
everything, but looking at the files and then finding your way: Yes,
that's definitely possible.
[reproducible in what way?]
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.
that sounds nice in theory, e.g. right now we're getting e.g.
timestamp in zip-files/jar files that differ despite being the same
input data. But I wonder whether bazel can help with that as well. And
yea, true that make is depending on environment variables to some
extent, but if bazel shields the build from environment variables,
that also means that converting to bazel is more work, since you'd
them find another way of passing stuff that's currently relying on the
environment..
I wouldn't say it is heavily relying on environment variables, after
all that's why we have configure and generate the config headers and
config_host.mk file reflecting configure's result.
I'd already be happy if identical on the same machine – but currently
it isn't really make/the build system that prevents this.
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.
looking forward to it. As mentioned in another mail I strongly suggest
to aim for an automated conversion process.
ciao
Christian