I’ve spent some time trying to dig through what bazel does and does not support. I’m personally a bit biased in favor of bazel, but I’m concerned it might not fit the requirements or desires that we have. I have no idea how much bazel has improved, so please let me know if any of these are inaccurate:
I would be happy about:
- Sane, easy to write and extend build language
- Easy to flip between static and dynamic linking for local development
- Monorepo makes setting up an ASAN/MSAN build significantly easier, and valgrind is slow
I’m concerned about:
- We need to support linux+Mac+windows. Linux is easy, Mac probably works, but it looks like windows needs a lot of special cases.
- The libressl dependency will be awkward to handle for every blaze reason possible. It’s not bazel-ified, and bazel doesn’t have integration with pkg-config to be able to rely on the system libressl.
- I’m a little unenthused about the monorepo approach without remote execution of build rules and remote cache. If we go with the model that everything required to run msan should be tracked by bazel, Changing from -O2 to -O0 to debug something would cause one to need to recompile libc++ and libressl, which hurts. Apparently remote caching now exists in bazel, but it’s not something we would likely feel good running for community developers, who would be stuck with very long builds.
Looking at the C++ roadmap for bazel, I see some of my concerns on there. I think our strict requirements are to be able to handle linux, Mac, and windows builds well, and be able to sensibly handle the libressl dependency. One would likely be able to hack around most of everything else (e.g. lack of
make install equivalent in bazel). As far as I’ve been able to see, CMake can handle our requirements well, today, so I think I’m still leaning towards an eventual rewrite into CMake.
If that ends up being the case, this would leave you with two ways forward:
- Wrap a CMake build system in bazel. This seems maybe possible with a
repository_rule, but I’m also reading a lot of complaints about it, so I have no idea. Better support for this is on the roadmap.
- Maintain bazel as a parallel build system. If it means community involvement and participation, I’m not going to stand in the way of having bazel as a secondary build system, and we can talk further about how to most sensibly fit FDB into bazel’s view of the world, but we would require that any upstreamed changes work when built with CMake.
And although I’ve leapt on handling your PR, it’s not like I’m the voice of FDB, so other opinions/commentary are clearly welcome.
: One can argue that we don’t have sane handling of libressl regardless of what we do. Our docker image contains a custom build of it, as we need a static library linked with -fPIC. Maybe that’s better than being in a monorepo, because you’ll only ever compile it once, but maybe not as you’d need a special version of it for asan/msan anyway…