@wscott Most important feedback is that BitKeeper’s build system needs to be modified such that the installation directories follow the common Linux filesystem hierarchy standard. Currently, it’s not possible to package BitKeeper for any of the current Linux distributions because of these short-comings, see the discussion in: Packaging BitKeeper for Linux distros is broken.
Moved this post to its own topic in the “Bugs” category rather than as a comment to a thread about how to report bugs.
Disclaimer: I’m not an active bk user. I’ve been bk-curious for a while now (Larry McVoy singing the praises of interweaved deltas got my interest), but the lack of “native” packaging has been a roadblocker for me to really try and pick it up.
Packaging has been a long-standing issue, actually, see also “A plan for packaging” that contains a rough roadmap, apparently started by BitKeeper staff. Little is its own kind of big issue. Keeping Windows working seems to be its own separate problem, too.
These issues have been mostly identified for three years, but not yet fully tackled. I think at this point, there’s just an issue with nobody having quite enough motivation to push for it, especially since it’s a relatively intimidating task and you probably have to keep at least Windows, macOS and GNU/Linux happy to start with. Considering BitKeeper, Inc. is effectively retired but has a bit of money left, maybe @mcvoy could be convinced to put up a bounty on this? Packaging is probably a major adoption roadblock for more people than just me.
Incidentally, pure make(1) doesn’t seem to be inherently hostile to packaging. As long as a Makefile handles $DESTDIR, $PREFIX, make install and uses standard pkg-config to find libraries, that should be good enough.
That plan for packaging thread is still reasonable. Many of the issues identified in that thread have been addressed but several more remain.
I no longer work on bk and again have a fulltime job somewhere else. So, unfortunately, I don’t have time to do much more that answer occasional questions and keep this forum running. That job did require me to become an expert in Cmake and I can agree that is probably the best path forward for building bk itself.
(The rest of this post is my opinion that is likely not shared by Larry)
For the people in that thread who insist on packaging bk properly where all libraries and dependencies are split out then the first step is going to be divorcing the bk command line from the GUIs.
The GUIs are written in Little is built on an old version of Tcl/TK. It was never accepted by the Tcl maintainers and so has become an unmaintained fork of Tcl. Unfortunately, some pieces of the bk command line were written in Little as well. Most notably ‘bk repocheck’ uses a little script. Somewhere I have a set of code that restores repocheck to be written in C.
We will need a bk executable that is functional with building the tcl/tk components. And the regressions will need to be split out as well.
Without the GUIs bk will need:
- pcre
- zlib
- lz4
- tomcrypt (this could be removed as explained in the other thread)
- tommath
Yes, Windows support has a lot of other dependencies and we are mostly talking about packaging bk for Unix distributions but any changes need to be made in such a way to not break Windows support.
Another part of the bk source code that may give some people heartburn is that bk/src/libc/stdio includes a very customized copy of the NetBSD Stdio library and the bk source code is very dependant on these customizations. They are used for a fast zero-buffering fgetline() call and layering transforming filters between stdio and the underlying file descriptors.
The main difficulty with the BSD stdio library is that occasionally we have symbol conflicts with the libc that need to be addressed.
https://github.com/bitkeeper-scm/bitkeeper/blob/master/src/libc/stdio_remap.h