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

Hi Christian,


Sorry for my late reply.
(It seems that there’s sometimes a delay in sending or receiving 
messages on the mailing list — is that normal behavior?)
Thank you very much for all the detailed information you shared.

As I mentioned briefly in my previous email, my opinion about Bazel has 
changed, and I have now decided to stop my development work on it.
Still, I’d like to share some of my follow-up thoughts in response to 
your message.

------------------------------------------------------------------------

> bazel would also have to create the config_foo.h headers or that would
> require a massive list of defines/command line arguments to the
> compiler, and that would be a problem since we already did exceed
> commandline length limits in the past, especially on windows, have to
> put arguments into temporary files that the command can read in some
> cases to stay within the limits...
Yes, I really struggled with that part.
Implementing pre-generated headers in Bazel was quite difficult, 
especially for generating the |udkapi| and |offapi| headers using 
|codemaker|.
That area caused a lot of trouble for me.

------------------------------------------------------------------------

> And there still just be the necessary complexity in supporting so many
> switches - you still need to be able to tell bazel to skip certain
> parts, to only include some portion of others, to use different
> variants of a third thing depending on the circumstances, would still
> need to provide stuff like the various foo_LIBS/FLAGS to pass them to
> externals that are built. In the current case that's in the
> config_host.mk – primarily the BUILD_TYPE on a macro level and the
> ENABLE_FOO (or sometimes WITH_FOO) on a micro level. All that would
> also have to be represented in bazel, as would the flags for the
> external components.

I think this could be simplified to some extent by using Bazel’s 
|platform()| and toolchain features.
This way, we could manage various environments — such as x86/x64, 
Windows, and Linux — without relying on separate flags.

```
platform(
    name = "linux_x86",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:x86_64",
        ":glibc_2_25",
    ],
)

```


In addition, regarding UI backends, it might be possible to consolidate 
multiple flags such as |ENABLE_GTK3/GTK4/QT6| into a single multi-valued 
flag like |--define ui=gtk3|gtk4|qt6|headless|.

```
# //flags/ui_backend.bzl
def ui_backend_settings(name):
    native.config_setting(name = name + "_gtk3", values = {"define": 
"ui=gtk3"})
    native.config_setting(name = name + "_gtk4", values = {"define": 
"ui=gtk4"})
    native.config_setting(name = name + "_qt6",  values = {"define": 
"ui=qt6"})
    native.config_setting(name = name + "_headless", values = 
{"define": "ui=headless"})

# //vcl/BUILD.bazel (conceptual example)
load("//flags:ui_backend.bzl", "ui_backend_settings")
ui_backend_settings("ui")

cc_library(
  name = "vcl_backend",
  deps = select({
    "//flags:ui_gtk3": ["//vcl/gtk3:gtk3_impl"],
    "//flags:ui_gtk4": ["//vcl/gtk4:gtk4_impl"],
    "//flags:ui_qt6":  ["//vcl/qt6:qt6_impl"],
    "//flags:ui_headless": ["//vcl/headless:impl"],
    "//conditions:default": ["//vcl/gtk3:gtk3_impl"],  # default
  }),
)

```

By consolidating UI backend management into a single multi-value 
setting, I think the complexity could be reduced somewhat.
(Although I haven’t tested this yet, so I’m not sure if it will actually 
work.)

------------------------------------------------------------------------

> That's also quite trivial, so remember the small nodejs package that
> apparently thousands of people used that was just a simple left-pad
> function or something that the author removed and broke all those
> packages?
> For some things it is just not worth using an external library.
That makes sense — I completely agree.
Looking back, I realize I might have trusted external libraries a bit 
too much.

------------------------------------------------------------------------

> If there
> at some point would be a "here's the buildsystem converted to bazel"
> dump with the hundreds of bazel files it is very hard to troubleshoot
> stuff, especially when you're not familiar with bazel.

Absolutely.
Especially since those who are skeptical about migrating to Bazel would 
then have to debug it — that would be quite unfair.
So, for now, I’ve decided to stop the development effort altogether.

------------------------------------------------------------------------

Thanks again for all your detailed explanations and thoughtful discussion.
I’ve learned a lot from this conversation, and the attempt itself was a 
great experience.


Best regards,
Haruhiko Nishizaki

--
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