On linux I can take a fresh clone and run bazel test -c opt //.. and it will build and run all tests cleanly. Macos builds fine, but a few tests still needs tweaks.
Still considering how to get the Windows build working in this setup
Changes in this branch:
fixed a bunch of compiler warnings
upgraded zlib lz4 pcre tomcrypt tommath to current versions and removed the source from the tree. These are all fetched using bazel
pcre v2 and tommath were major API changes
fixed a date issue that starts in 2018 and caused regressions to fail
fix a bug in the lines.h library (C std::vector clone) that failed in modern C standards
And yes I am using AI to do some of the heavy lifting here.
Checking to see what people think. I am hoping I can get Windows builds working again and then release a new version.
I have my local hacking areas which limp along. One thing, I sort of dug into a long time ago was GCC shifted and some of our magic L(something) code stopped working, silently. It compiled, but stuff would barf. Clang was fine. I started to track down the shift in gcc to submit a regression, and got sidetracked. I hacked a different L() macro to be less magic, and changed a lot of places.
It sounds like you are seeing things work without hackery? That’s cool. I look later. Thanks!
Yeah I fixed that bug in the bazel branch.
And now I specify the C11 standard.
At the moment I have the AI off figuring out how to restore the Windows build that has been broken for a lot time. It is looking like I can build the full Windows installer on a Linux machine.
If I get a few people to say this works for them and is better than what we had then I will make this the default branch and setup github the run regressions on every PR. (maybe)
Some time ago, I ran into a case where I wanted to rename a component within a nested collection.
The docs state that component renames were not implemented because that was not a priority.
Since AI is now being used to help solve some issues, would it be possible to put it to the task of figuring out how to implement support for component renames?
When Larry wrote that component renames where not hard he either had his marketing hat on or hadn’t actually thought about the problem that hard.
This is a core difficult bk problem because of the way that bk handles file conflicts and renames. A moving component can interact with other components or files in the product or other components. And this needs to be resolved interactively in the bk resolver. So you have to present the problem to the user with enough context for them to understand the issue and resolve it correctly. It is an area where bk is already somewhat clunky and you are adding a whole new layer of issues.
I am sure the mainline AIs can get a long what towards writing the code for this, but the problem and solutions desired would need to be spec’d out and tested very carefully.
Alright, thanks for your reply. Now for something hopefully a little more on-topic. Would it be possible to have CMake as a build option, at least on Linux?
Unlike Mac and Windows, Linux pays some attention to bootstrappable builds. Having Bazel as the build system makes building BitKeeper reliant on the availability of another self-bootstrapping compiler besides GCC/Clang, the JDK.
Unless BitKeeper is getting some code rewritten in Java (like what is happening now with Git and Rust), it may be a good idea for BitKeeper to remain buildable on Linux without involving a second self-bootstrapping compiler.
I understand if Bazel continues to be used on Mac and Windows to allow you to build and distribute binaries easily on those platforms. However, I hope this request for an alternative build system will be considered for the benefit of people building BitKeeper from source on Linux.
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.
