@GrahamcOfBorg build bmake

I had a local bmake recipe that I think has some advantages which could be merged in here. I found a stable versioned URL for the source, for one thing, and I think you used the wrong version number.

Also, you don't need to explicitly depend on gnugrep or coreutils, do you? I thought stdenv just always pulled those in. And I used the getopt from unixtools in hopes that this might build on non-Linux too, although I didn't test it anywhere except on NixOS, so I dunno if that helped.

stdenv.mkDerivation rec { 
  name = "bmake-${version}";
  version = "20181221";

  src = fetchurl { 
    url = "http://www.crufty.net/ftp/pub/sjg/${name}.tar.gz";
    sha256 = "0zp6yy27z52qb12bgm3hy1dwal2i570615pqqk71zwhcxfs4h2gw";
  };

  nativeBuildInputs = [ unixtools.getopt ];

  patches = [ ./bmake-bootstrap.patch ./bmake-tests.patch ];
}

I was hoping the two patches would be accepted upstream, although I didn't try to submit them anywhere.

bmake-bootstrap.patch was as follows:

--- bmake/make-bootstrap.sh.in.orig     2019-02-19 10:55:21.733606117 -0800
+++ bmake/make-bootstrap.sh.in  2019-02-19 10:56:02.150771541 -0800
@@ -4,6 +4,7 @@
 
 srcdir=@srcdir@
 
+prefix="@prefix@"
 DEFAULT_SYS_PATH="@default_sys_path@"
 
 case "@use_meta@" in

I don't remember why I thought it was important to set prefix there, but I think it made bmake work when not using the -r flag, maybe?

And bmake-tests.patch was an alternative to entirely disabling the unexport-env test:

--- bmake/unit-tests/unexport-env.mk.orig       2019-02-19 10:24:14.356713136 -0800
+++ bmake/unit-tests/unexport-env.mk    2019-02-19 10:25:43.838775388 -0800
@@ -3,8 +3,8 @@
 # pick up a bunch of exported vars
 .include "export.mk"
 
-# an example of setting up a minimal environment.
-PATH = /bin:/usr/bin:/sbin:/usr/sbin
+# preserve PATH so commands used in the "all" target are still available
+PATH := ${PATH}
 
 # now clobber the environment to just PATH and UT_TEST
 UT_TEST = unexport-env

@jameysharp ccee411 fixes all of this and is now in master. Thanks for the feedback!

Also, you're right, gnugrep and coreutils weren't needed; I think I left that as an artifact of testing something while I authored the first draft privately.

getopt or unixtools.getopt should both work fine I think and are portable enough; e.g. getopt was building OK on Darwin recently, though the builders are somewhat sick it seems.

Tested this by building libfsm from #63229.