Bazel build files

[JannisFengler]

Currently, liboqs is built with cmake. Is there interest in Bazel build files?

[baentsch]

So far we didn't see the need -- nor have the experience in the team (AFAIK). Would you be willing to contribute and maintain this? Which projects/users do you have in mind supporting with this?

[JannisFengler]

With additional Bazel build files, builds would be reproducible, which simplifies the reproduction of errors.

The concrete project would be: https://github.com/eomii/rules_ll/
I have been working with my colleagues on this upstream Clang/LLVM-based Bazel toolchain, which supports:

• AddressSanitizers
• LeakSanitizers
• MemorySanitizers
• BehaviorSanitizers
• ThreadSanitizers
• etc.

It would be cool to use these tools to make liboqs safer and more robust.

[baentsch]

With additional Bazel build files, builds would be reproducible, which simplifies the reproduction of errors.

We already use sanitizers in our CI. Can you give an example of errors that are not covered that way or that are not reproducible when using cmake?

[dstebila]

Our CMake build system is now quite complex with many different options, I'd be very reluctant to try to reproduce all of that in a second build system unless there is an extremely compelling reason to do so.

[ghost]

I would like to dig up this discussion.

Bazel is used by large companies such as Google or Uber. I think having a native Bazel build system for liboqs would help these companies adopt liboqs.

Similar to liboqs, LLVM is officially using CMake as its build system. However, some people from Google (I think?) are also maintaining a Bazel build system for it, in a non-intrusive way (everything Bazel-related live under utils/bazel).
The way it works with LLVM is that contributors can freely contribute to the project without caring about the Bazel build system, and from time to time some Bazel maintainers come and fix it.

Do you think we could achieve something similar?

I'm currently trying to write the Bazel build system for liboqs, and the most complex thing was to port oqsconfig.h.cmake to Bazel.

[baentsch]

If you're willing to maintain this, no objection from my side -- as long as the understanding is that we maintain cmake as the primary build system (until there's a compelling reason to move away from it). It might be worth while checking with Google via the "LF connection" whether that might be indeed something that would let them use OQS... That said, actually any corporate commitment to use OQS would be good to hear about to inform issues like open-quantum-safe/tsc#1

[dstebila]

Would Bazel import various settings from CMake, or would we need to maintain them in parallel? At this point we have a lot of CMake options -- many autogenerated based on the algorithms, but also many not. Would we intend to have our Bazel build support all the configurations/platforms that our CMake build supports?

[ghost]

Would Bazel import various settings from CMake, or would we need to maintain them in parallel?

Kinda both. The idea would be to use oqsconfig.h.cmake as the single source of truth.

I've written a small Bazel rule to create a "Bazel compatible" config file from oqsconfig.h.cmake:

https://github.com/thb-sb/liboqs/blob/af5a03d9d3e3f0032316891a1fe9779f47ac966a/bazel/src/BUILD.bazel#L27

At this point we have a lot of CMake options -- many autogenerated based on the algorithms, but also many not.

CMake would remain the source of truth. Using jinja2 we could easily port the set of CMake options to Bazel (see https://github.com/thb-sb/liboqs/blob/af5a03d9d3e3f0032316891a1fe9779f47ac966a/bazel/src/oqsconfig.bzl#L97 in my fork, I've copied/pasted everything here, but we could easily do it with jinja2 I guess?)

Would we intend to have our Bazel build support all the configurations/platforms that our CMake build supports?

I'm not going to claim that Bazel is easy to use when it comes to cross-compiling libraries, but it's not quite difficult to flag a library as compatible with only x86_64, aarch64 etc.
But I think we could safely say that the Bazel build system is as it is, with no warranty, i.e. it won't be the first-class citizen build system.

Last weekend I've played with the PQClean/pq-crystals repos, and I managed to build their projects using Bazel, with support for avx2, Neon/SVE2.