Previously, we installed std by omitting the tools directory. Now, there are
occasions where you actually want to use things like tools.haxelib from within
your project, for example to create something that interfaces with the haxelib
API. So we now just remove all files in there that were created during the main
build in postBuild.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Neko seems to think it is running in 32bit, even though it is compiled for
64bit. The fix is included in 1.8.3, which is not yet released as of now, so we
add a temporary fix until the release.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As well as for neko, we now have way less cruft within the mkDerivation
attribute set. We also now use make to build haxe, which will include haxelib
and haxedoc as well.
The main reason why I was doing this was because the package didn't build and
still was referencing mawercer.de, which does not contain those tarballs
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should simplify the input of the derivation builder significantly and of
course we don't need to rely on mawercer.de to supply the needed files. Also,
the derivation name doesn't include "-cvs" anymore, as we're building from the
release tarball.
In addition, we don't need the patch anymore, as it was so simple that it could
be done easily with sed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The openjdk BOOT_CYCLE bootstrap doesn't use the binaries built in the first stage for the second stage, so we get a bunch of errors like:
/bin/sh: /nix/store/wdgl7xl9b72hn212l0672ad5sn7vh44y-openjdk-bootstrap/bin/native2ascii: No such file or directory
Instead, just build each stage as a separate derivation
This reverts commit 7f871719d57fbb7460b658c1732a810b50238a0d.
Apparently, GHC comes with template-haskell, so there's no point in installing it separately.
