I have been playing with getting BitKeeper supported on Nix, but
suddenly find that things are getting very busy.
If someone wants to mess with Nix here is a package I started:
{stdenv, fetchurl, perl, gperf, bison, groff,
pkgconfig, libXft, fontconfig}:
stdenv.mkDerivation rec {
name = "bitkeeper-7.2ce";
src = fetchurl {
url = "http://www.bitkeeper.org/downloads/7.2ce/bk-7.2ce.tar.gz";
md5 = "ba76ad934d7d647a1714cd8b24e72ae3";
};
buildInputs = [ perl gperf bison groff libXft pkgconfig ];
buildPhase = ''
cd src
make -j6 p
make image
'';
installPhase = ''
./utils/bk-* $out/bitkeeper
mkdir -p $out/bin
$out/bitkeeper/bk links $out/bin
chmod g-w $out
'';
meta = {
description = "BitKeeper";
longDescription = ''
Long BitKeeper desc
'';
homepage = http://www.bitkeeper.org/;
license = stdenv.lib.licenses.asl20;
platforms = with stdenv.lib.platforms; all;
maintainers = [ #Add your name here!
stdenv.lib.maintainers.wscott
];
};
}
This builds something that looks like this:
$ ls -l /nix/store/pqq0n30vychsy17b7py3d13z5gzyjj6f-bitkeeper-7.2ce
total 8K
dr-xr-xr-x 2 root root 4096 Dec 31 1969 bin
dr-xr-xr-x 8 root root 4096 Dec 31 1969 bitkeeper
$ ls -l /nix/store/pqq0n30vychsy17b7py3d13z5gzyjj6f-bitkeeper-7.2ce/bin
total 4K
lrwxrwxrwx 2 root root 72 Dec 31 1969 bk -> /nix/store/pqq0n30vychsy17b7py3d13z5gzyjj6f-bitkeeper-7.2ce/bitkeeper/bk
$ ls -l /nix/store/pqq0n30vychsy17b7py3d13z5gzyjj6f-bitkeeper-7.2ce/bitkeeper/
total 3852K
-r-xr-xr-x 6 root root 1489 Dec 31 1969 applypatch
-r-xr-xr-x 6 root root 696 Dec 31 1969 b64wrap
-r-xr-xr-x 2 root root 2556888 Dec 31 1969 bk
-r--r--r-- 5 root root 921738 Dec 31 1969 bkhelp.txt
...
But it doesnāt actually work in practice because of how bk works. Normally /usr/bin/bk is a symlink to something like /opt/bitkeeper/bk where the package was installed. The code in src/port/platform.c tries to find the pathname to that directory for use internally by looking up ARGV[0] on the userās PATH and then following the symlink. However in Nix that symlink is actually a series of links. And the readlink() in src/port/platforminit.c doesnāt handle that case.
We probably need to fix bk to handle that case. Or perhaps replace /nix/store/HASH-bitkeeper/bin/bk with a shell script that just calls ../bitkeeper/bk.
I pushed a fix for that symlink issue to bk:// bkbits.net/u/bk/dev
So now the above form should work. But unfortunately, at the moment our bkweb code doesnāt support downloading a tarball of a certain REV directly so I canāt update the recipe to use the new code.
I hope to release bk-7.3 soon based on that tree and then this nixpkg should work.
Iām a NixOS maintainer and developer, so Iām willing to upstream a working package expression, FWIW. Itāll need to build cleanly on NixOS as well - have you been testing on NixOS, or just on Nix-on-some-other-Linux? (NixOS has enhanced chroot security features that can cause builds to fail sometimes, if unaccounted for.)
Also, there should be no need to wait for 7.3 if the symlink fix is all thatās really preventing things from working. We run into similar upstream code a lot, and have a tool called wrapProgram that can just do exactly what you say: sit in bin, and do nothing but run exec /path/to/bk $@. This is very often needed for things like Java programs; hereās an example in a package I maintain:
Alternatively, if you have a unified diff, you can ship .patch files to be used by the build system, as a last resort, by specifying patches = [ ./fix-symlink-resolution.patch ]; inside the Nix file. This is how we backport needed fixes from upstreams.
I only run the nix package manager from Linux, but I have done builds in a chroot before to make sure they are clean. If you would be willing to maintain a valid bk package, that would be good for me.
The bk-7.3ce released will be soon. That one will includes code to use the systemās zlib, lz4, pcre, tomcrypt & tommath libraries (if we can find them). (Thanks @calhariz for the initial push there.)
Here is the nix bk package I am currently working on:
It builds a correct tree that seems to work fine. It also demonstrates how the new version will support the ability to override the locations of the libraries. That file I am overwriting is normally auto-generated, but it has very simplistic logic to search for system libraries. For something like Nix is was easier to just write the correct file.
Once we release bk-7.3 I will make a pull request to nixpkgs to include this.
With the bk-7.3 release that whole ugly block in the middle that writes conf.mk is gone and it still builds correctly. We look run pkg-config to see about library locations and nix is helpful enough to keep those updated.
However, the GUI tools from this build donāt work. When bk runs our local wish it hangs when trying to open the first X window. I will need to figure out what is happening there. Nevermind, user error. Works fine.
