I’ve been playing too much Monster Hunter World. I hear Bazel and I go oh god not again. This might be an interesting one to add dotnet core support though.
I’m the maintainer although my time to contribute lately has been limited. I don’t do as much .Net as I used to these days. I’ll happily accept patches from anyone who wants to help get it across the finish line.
It turns out that Google, Facebook, Twitter and many others have needed a solution to this use case for many years now. They came up with Bazel, Buck, Pants and many others, respectively. So all we needed to do was add Haskell support to one of these existing solutions. We chose Google’s Bazel.
We looked at Buck. Actually initial version of bazel rules was somewhat of a blind copy of what Buck was doing. It was the main contender along Bazel for a system we’d go with. The reasons we didn’t go for Buck are (that I can remember off the top of my head months later):
The rules are fairly limited. They don’t play nicely with Java, C, … as far as we could see. We spoke with Simon Marlow who is at Facebook using those rules for an experience report and some general advice and it obviously works for their use-case but I think we wanted a bit more.
To do anything to Buck rules (change, extend, add new ones), you have to change Buck itself. You then have to make sure all your users are using the right version. There’s nothing like Skylark which lets you add rules post-facto. In bazel you can stick the commit revision of rules you want in WORKSPACE and you’re good to go.
It didn’t work out of the box for me personally on NixOS. The buck daemon would not start. This made using Buck an awful experience for me. I would have to spend time into making it work properly instead of working on the rules.
Bazel is a lot better documented. It leaves a lot to desire still I think but compared to Buck docs, it’s great.
General community around Bazel seems bigger. This probably follows from (2.). This was and continues to be extremely useful during development because very often we’ll go “oh, let’s look at what Go rules are doing for how do do XYZ”.
From what I remember, Buck actually does “dirty” builds. It builds Haskell then very carefully removes just enough temporary craft to allow somewhat stable rebuilds that are still iterative. This makes partial rebuilds fast but makes rebuilds potentially fail. I don’t know if it happens in practice but it seemed somewhat unprincipled.
This was settled on few months ago so I don’t remember the details and hopefully didn’t make anything up but don’t quote me on anything from here. Overall Bazel just seemed like a better basis for developing usable rules that we wanted.
Awesome motivation of bazel. I tried to understand it a few years ago, but it was too complicated for me. Seriously - it’s really complicated. It feels like trying to understand a whole system, like http ecosystem, rather than just a simple build tool.
I’ve been playing too much Monster Hunter World. I hear Bazel and I go oh god not again. This might be an interesting one to add dotnet core support though.
Support for dotnet core is already in progress and is partially usable: https://github.com/bazelbuild/rules_dotnet
I’m the maintainer although my time to contribute lately has been limited. I don’t do as much .Net as I used to these days. I’ll happily accept patches from anyone who wants to help get it across the finish line.
I wonder why they used Bazel. Buck supposedly already has Haskell support.
A comment from my coworker:
We looked at Buck. Actually initial version of bazel rules was somewhat of a blind copy of what Buck was doing. It was the main contender along Bazel for a system we’d go with. The reasons we didn’t go for Buck are (that I can remember off the top of my head months later):
This was settled on few months ago so I don’t remember the details and hopefully didn’t make anything up but don’t quote me on anything from here. Overall Bazel just seemed like a better basis for developing usable rules that we wanted.
Thank you!
Awesome motivation of bazel. I tried to understand it a few years ago, but it was too complicated for me. Seriously - it’s really complicated. It feels like trying to understand a whole system, like http ecosystem, rather than just a simple build tool.