My context for what Linux and the “opensource world” want BitKeeper to look like would be what would a Debian maintainer need to package bk. Having it build with bazel is not a showstopper, but the main problems would be that the BitKeeper source includes some (old) vendor copies of packages and they are are old. Removing all the external dependencies has been the primary focus of this branch. The original makefile tried to make them optional, but didn’t really succeed and it made everybody’s build slightly different. You don’t need a build tool, but a packaging tool as well. This is what Bazel does. For Cmake you use the new clunky FetchContent or use Conan. I hate conan.
Libraries removed from bk source and updated to current versions in the bazel branch:
- zlib
- tomcrypt (upgraded)
- tommath (partially upgraded, development of tomcrypt appears to have stopped, so tommath is the last version supported by tomcrypt)
- pcre (also upgrade to current version)
- lz4
- Tk
Two main problems remain.
We have a older snapshot of the netbsd stdio library. This is used extensively inside of bk to add processing layers to files. This is how the s.ChangeSet file is compressed and can have append-only additions to it. This one is hard to remove, but is relatively small.
The L language. A number of pieces of bk are written in the L language which is a C frontend to Tcl. This was added directly to the Tcl source and so unless we remove L from bitkeeper or someone takes over maintaining L the Tcl source remains embedded in bk and stuck at v8.6.4.
Unfortunately this last one is a showstopper for Debian.
You might be interested in this thread:
A plan for packaging
As far as removing your bootstrapping step, don’t use Bazel, use Bazelisk. It is a tiny single go binary that downloads and runs bazel out of a cache directory. I could change the Makefile to run bazel for you, but I haven’t remove the old Makefiles yet.
I this point I need people to actually try the build and see if it works.