Hi *, On Mon, Oct 13, 2025 at 8:07 PM jijinbei <[email protected]> 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
