The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
It turns out that cargo implicitly depends on rustc at runtime: even
`cargo help` will fail if rustc is not in the PATH.
This means that we need to wrap the cargo binary to add rustc to PATH.
However, I have opted into doing something slightly unusual: instead of
tying down a specific cargo to use a specific rustc (i.e., wrap cargo so
that "${rustc}/bin" is prefixed into PATH), instead I'm adding the rustc
used to build cargo as a fallback rust compiler (i.e., wrap cargo so
that "${rustc}/bin" is suffixed into PATH). This means that cargo will
prefer to use a rust compiler that is in the default path, but fallback
into the one used to build cargo only if there wasn't any rust compiler
in the default path.
The reason I'm doing this is that otherwise it could cause unexpected
effects. For example, if you had a build environment with the
rustcMaster and cargo derivations, you would expect cargo to use
rustcMaster to compile your project (since rustcMaster would be the only
compiler available in $PATH), but this wouldn't happen if we tied down
cargo to use the rustc that was used to compile it (because the default
cargo derivation gets compiled with the stable rust compiler).
That said, I have slightly modified makeRustPlatform so that a rust
platform will always use the rust compiler that was used to build cargo,
because this prevents mistakenly depending on two different versions of
the rust compiler (stable and unstable) in the same rust platform,
something which is usually undesirable.
Fixes#11053
Bazel 981b7bc1 depends on protobuf-2.5 and won't work with 2.6 (and in
bbe84fe3d upgraded straight to protobuf 3.0.0-alpha3); this commit fixes
the dependency to depend on protobuf2_5 specifically.
The bazel compile.sh needs `which` on the PATH; so this commit adds that
as a dependency.
Setting JAVA_HOME to ${jdk} broke bazel when used with openjdk, with the
message:
Problem with java installation: couldn't find/access rt.jar in /nix/store/z9vc0vzyzhnpl5l5inmqdnvdnbxmmmg7-openjdk-8u60b24
This is because if you set JAVA_HOME, bazel will look for rt.jar in
$JAVA_HOME/lib and $JAVA_HOME/jre/lib, but the nixpkgs openjdk
distribution puts rt.jar in ${jdk}/lib/openjdk/jre/lib for some reason.
To fix this, this commit uses the ${jdk.home} passthru value to use the
appropriate JAVA_HOME for the given jdk.
As bazel now works with openjdk, and openjdk is free while oraclejdk is
not, this commit changes the default jdk for bazel to openjdk.
Since this package didn't have a listed maintainer, I'm claiming it.
For now, let's remove `leaveDotGit`. The only visible effect I could see
was that `cargo --version` won't report the git commit anymore, but
that's only a minor issue compared to the build breaking often.
Fixes#8566 and closes#8862.
Update snapshot to avoid rust-lang/cargo#976, which otherwise breaks the
build.
Also move the `cargoSnapshot` derivation inside a set in
pkgs/top-level/all-packages.nix in order to hide the `cargo-snapshot`
packages from `nix-env -qa`, since it's only used to build the `cargo`
package.
This happened in VM builds:
make flags: SHELL=/nix/store/dbxpkswwc7rh6g1iy6dwqklzw39hihb1-bash-4.3-p33/bin/bash
/nix/store/jm26xg0h3jcrg4bbrwiqx3jpirscdk0p-stdenv/setup: line 658: 5957 Segmentation fault make ${makefile:+-f $makefile} ${enableParallelBuilding:+-j${NIX_BUILD_CORES} -l${NIX_BUILD_CORES}} $makeFlags "${makeFlagsArray[@]}" $buildFlags "${buildFlagsArray[@]}"
Instead, discover it automatically when building the package.
This makes `buildRustPackage` more future-proof with respect to changes
in how `cargo` generates the hash.
Also, it fixes broken builds in i686 because apparently, cargo generates
a different registry index hash in this architecture (compared to
x86-64).
It seems that when you pass `leaveDotGit = true` to `fetchgit`, sometimes
the output can still change (i.e. it's not completely deterministic).
This could be due to changes in the upstream git repository...
This makes buildRustPackage portable to non-Linux platforms.
Additionally, now we also save the `Cargo.lock` file into the fetch output, so
that we don't have to run $cargoUpdateHook again just before building.
Instead, move that code into buildRustPackage.
The setup hook was only doing part of the work anyway, and having it in
a separate place was obscuring what was really going on.
It turns out that `cargo`, with respect to registry dependencies, was
ignoring the package versions locked in `Cargo.lock` because we changed
the registry index URL.
Therefore, every time `rustRegistry` would be updated, we'd always try
to use the latest version available for every dependency and as a result
the deps' SHA256 hashes would almost always have to be changed.
To fix this, now we do a string substitution in `Cargo.lock` of the
`crates.io` registry URL with our URL. This should be safe because our
registry is just a copy of the `crates.io` registry at a certain point
in time.
Since now we don't always use the latest version of every dependency,
the build of `cargo` actually started to fail because two of the
dependencies specified in its `Cargo.lock` file have build failures.
To fix the latter problem, I've added a `cargoUpdateHook` variable that
gets ran both when fetching dependencies and just before building the
program. The purpose of `cargoUpdateHook` is to do any ad-hoc updating
of dependencies necessary to get the package to build. The use of the
'--precise' flag is needed so that cargo doesn't try to fetch an even
newer version whenever `rustRegistry` is updated (and therefore have to
change depsSha256 as a consequence).
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
Instead, figure out VERSION at build-time. This simplifies using
overrideDerivation (no need to copy and modify installPhase).
Also add a check that the file exists (catch potential failure early).
New build system using configure script and GNU Make 4.0, and new
releases of the following using the new build system:
execline 2.0.0.0
s6 2.0.0.0
s6-dns 2.0.0.0
s6-linux-utils 2.0.0.0
s6-networking 2.0.0.0
s6-portable-utils 2.0.0.0
skalibs 2.0.0.0
Cargo downloads your Rust project's dependencies and builds your
project.
The cargoSnapshot derivation simply uses a binary build, because
it's not easy to build cargo from source yet.
In the future, it's expected that we'll also add a derivation for
building cargo from source.
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
This includes a lot of fixes for cross-building to Windows and Mac OS X
and could possibly fix things even for non-cross-builds, like for
example OpenSSL on Windows.
The main reason for merging this in 14.04 already is that we already
have runInWindowsVM in master and it doesn't work until we actually
cross-build Cygwin's setup binary as the upstream version is a fast
moving target which gets _overwritten_ on every new release.
Conflicts:
pkgs/top-level/all-packages.nix
Both branches have quite a lot in common, so it's time for a merge and
do the cleanups with respect to both implementations and also generalize
both implementations as much as possible.
This also closes#1876.
Conflicts:
pkgs/development/interpreters/lua-5/5.2.nix
pkgs/development/libraries/SDL/default.nix
pkgs/development/libraries/glew/default.nix
pkgs/top-level/all-packages.nix
For instance, a package can now say:
buildInputs = [ ant jre ecj ];
which would cause the Eclipse compiler to be used with the OpenJRE.
Similarly:
buildInputs = [ ant gcj ];
uses the GNU JVM with the GNU Java compiler.
Also, Ant no longer has a build-time dependency on a particular JDK.
It finds the JDK via $JAVA_HOME or $PATH (by looking up javac). This
way, we don't need to have separate packages like apacheAntOpenJDK and
apacheAntOracleJDK. It also seems reasonable: after all, installing
GNU Make doesn't give you a C compiler either. It does mean that
instead of
buildInputs = [ ant ];
you now need to write something like
buildInputs = [ ant jdk ];
* Remove package name
* Start with upper case letter
* Remove trailing period
Also reword some descriptions and move some long descriptions to
longDescription.
I'm not touching generated packages.
There are many more packages to fix, this is just a start.
Rules:
* Don't repeat the package name (not always that easy...)
* Start with capital letter
* Don't end with full stop
* Don't start with "The ..." or "A ..."
I've also added descriptions to some packages and rewritten others.
Unfortunately, leiningen will now pull in some dependencies via maven (via http) on `lein version' so the test at the end of builder.sh failed. This is okay because leiningen is used only as a interactive tool and no other package in Nixpkgs depends on it.
Signed-off-by: Moritz Ulrich <moritz@tarn-vedra.de>
This breaks some packages (notably liblapack) due to a broken macro
(CTEST_CUSTOM_POST_TEST). See NixOS/nixpkgs#762
This reverts commit ebc424c3ab.
Signed-off-by: Shea Levy <shea@shealevy.com>
The changelog is available at:
http://www.cmake.org/files/v2.8/CMakeChangeLog-2.8.11
I had to create a new patch from scratch, that's why it contains a lot
of differences. CMake developers has rewritten the files
(Modules/Platform/Linux.cmake and Modules/Platform/UnixPaths.cmake) to
comply to their coding style requirements and a lot of elements has
switched from upper to lower case.
Also, the previous patch partially consisted of commenting some
instructions mixed with line removals whereas mine is directlty
removing them in order to avoid useless evaluations and parsing in
resulting files.
Version 1.2.0 is way too old in order to build the latest chromium (29) version,
so let's get it up to date (especially because no other package is referencing
ninja, so it should be non-critical).
The dependency on unzip is not needed here, because GitHub also provides
archives in tar.gz format.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Vladimír Čunát
Danny Wilson
Ricardo M. Correia
William A. Kennington III
Desmond O. Chang
Edward Tjörnhammar
Aristid Breitkreuz
Pascal Wittmann
Ian-Woo Kim
Pascal Wittmann
Cillian de Róiste
Brandon Edens
Gabriel Ebner
Robin Gloster
Tobias Geerinckx-Rice
Tim Cuthbertson
Samuel Rivas
Peter Simons
koral
Eelco Dolstra
Thomas Tuegel
Moritz Ulrich
Rickard Nilsson
j-keck
Profpatsch
lethalman
Ragnar Dahlén
Nikolay Amiantov
Philip Potter
Austin Seipp
Stewart Mackenzie
Jude Taylor
Robert Irelan
Michael Raskin
Rok Garbas
Florian Friesdorf
Arseniy Seroka
Joel Taylor
Georges Dubus
Charles Cooper
Dmitry Belyaev
Eric Seidel
John Wiegley
Luis G. Torres
goodwillcoding
Rob Vermaas
Jordan Woehr
Bjørn Forsman
Shea Levy
Johannes Bornhold
Benjamin Saunders
Ludovic Courtès
John Ericson
Patrick Mahoney
bbarker
Alexander Flatter
Mateusz Kowalczyk
Henry Till
宋文武
Daniel Peebles
William Roe
aszlig
Domen Kožar
Petr Rockai
Mathijs Kwik
bbenoist
Evgeny Egorochkin