Any attempt to instantiate these expressions on an unsupported platform is
going to 'throw' an error. The call to 'assert' doesn't add any value to
that (and generates less readable error messages, too). Further details are
available at <https://github.com/NixOS/nix/issues/56>.
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
I got the following error in 4 consecutive attempts:
building rts/dist/build/AutoApply.debug_o
building rts/dist/build/AutoApply.thr_o
rts_dist_HC rts/dist/build/AutoApply.debug_o
/nix/store/1iigiim5855m8j7pmwf5xrnpf705s4dh-binutils-2.21.1a/bin/ld: cannot find libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers_o_split/gmp-wrappers__1.o
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.p_o] Error 1
Users might want to override the 'src' and 'name' of go from 'hg'.
I make the expression compatible with that.
Aside, I also set GOARM in the wrapper for it to build programs fine on
armv5tel by default.
The previous version seemed rather old and not even the examples from the
official site compile with that fossil. As there are no reverse dependencies,
this update should be trivial and hopefully doesn't hurt someones personal
feelings.
The gccinstall manual says that parallel building with a profiled
bootstrap is not supported. As we don't have much means of checking
if our profiled bootstrap with parallel build was good or bad, I
propose going to safe terrain.
Update julia and some of its dependencies
Split PCRE because a lot of packages depend on it and I am not sure we
want to test them in a hurry (and Julia specifies exact version).
I switch off the build of ocaml compilers to native code, and add
a 'passthru' that unison can use to see if it needs to call the native
or the bytecode compiler.
by removing the check for the 'binary' package, which is built-in from
that version onward. This is a workaround for the problem where ghc's
built-in libraries (like containers, array, binary) don't show up in
"ghc-pkg list" output.
svn path=/nixpkgs/trunk/; revision=34471
Removing a gcc flag, --enable-version-specific-runtime-libs, that put gcc libs
in a speparate directory instead of /lib; this broke the installation of
libgcc_s.a for the case of "--enable-shared" in mingw-w64. And we already have all gccs in directories apart.
I also add the option --enable-fully-dynamic-string, which is used in the
prebuilt mingw64 toolchain; this way nixpkgs creates ABI-compatible binaries
with mingw64 upstream. (told by jon_y on irc ##mingw)
svn path=/nixpkgs/trunk/; revision=34242
shared libraries are wrong.
It should run "-lstdc++ -lsupc++" if libstdc++-6.dll is available, and instead it runs
"-lstdc++" and therefore lack symbols.
I think simply few people use shared gcc libs on mingw.
svn path=/nixpkgs/trunk/; revision=34225
