Reintroducing mkRustCrate #31150

P-E-Meunier · 2017-11-02T20:07:50Z

Motivation for this change

This is another way to compile Rust programs, which uses Nix instead
of Cargo to manage dependencies. Compiling a package can reuse
previously compiled dependencies.

This uses a companion Rust crate called generate-nix-pkg to produce
the .nix files from a Cargo.lock.

Especially useful in combination with NixOps.

Things done

Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)
- NixOS
- macOS
- other Linux distributions
Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
Tested execution of all binary files (usually in ./result/bin/)
Fits CONTRIBUTING.md.

This is another way to compile Rust programs, which uses Nix instead of Cargo to manage dependencies. Compiling a package can reuse previously compiled dependencies. This uses a companion Rust crate called generate-nix-pkg to produce the .nix files from a Cargo.lock.

P-E-Meunier · 2017-11-02T20:24:33Z

I'd love documentation (at least hints?) on two things:

How I can add documentation for this into the manual, if appropriate.
This feature can allow us to maintain a "nix mirror" of crates.io. This would be useful because some crates depend on external libraries, and nix could provide an even better UX than cargo by including those automatically.
On the same line, how useful would it be to have a tool called for instance "carnix", that could be used to build and run packages just like cargo, but by calling nix-build?

nyarly · 2017-11-02T21:15:45Z

Take this for what it's worth, updating https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/rust.md is probably the right place. (I wasn't aware that markdown was an option when I updated the ruby.xml sibling document...)

You can both make it clearer where mkRustCrate lives viz-a-viz the existing alternatives, and explain how to use it.

It couldn't hurt to include a use of mkRustCrate in the PR as an example.

Ralith · 2017-11-03T00:50:53Z

It couldn't hurt to include a use of mkRustCrate in the PR as an example.

Perhaps a packaged version of generate-nix-pkg, which will surely be desired regardless?

dpc · 2017-11-03T06:34:02Z

How can I try it out? I tried by just downloading the main file, and using it locally in my project with:

$ cat default.nix 
{ pkgs ? (import <nixpkgs> {})}:

let
  mkRustCrate = pkgs.callPackage ../rust-utils.nix { };
in

mkRustCrate rec {
  crateName = "hackeraudit-cli";
  version = "HEAD";

  src = builtins.filterSource (p: t:
      pkgs.lib.cleanSourceFilter p t &&
      baseNameOf p != "target" &&
      baseNameOf p != "rusty-tags.vi"
  )  ./. ;

} pkgs.rustc

However I'm getting:

$ nix-build 
these derivations will be built:
  /nix/store/v3j7nva7vdx7nlpsajxn0kyv2y604mbf-rust_hackeraudit-cli-HEAD.drv
building path(s) ‘/nix/store/2q41d8ciy85hjgpvbcdf08d53gn7ymmv-rust_hackeraudit-cli-HEAD’
unpacking sources
unpacking source archive /nix/store/v98dlw9h7byn5m1s0kfv900d751n9n4q-cli
source root is cli
patching sources
configuring
no configure script, doing nothing
building
Building src/main.rs
error[E0463]: can't find crate for `error_chain`
 --> src/main.rs:2:1
  |
2 | extern crate error_chain;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

builder for ‘/nix/store/v3j7nva7vdx7nlpsajxn0kyv2y604mbf-rust_hackeraudit-cli-HEAD.drv’ failed with exit code 101
error: build of ‘/nix/store/v3j7nva7vdx7nlpsajxn0kyv2y604mbf-rust_hackeraudit-cli-HEAD.drv’ failed

so I'm not sure if it's a right approach.

Other than that it seems it currently does not support sourceRoot. I've added:

sourceRoot = (if lib.attrByPath ["sourceRoot"] null crate != null then crate.sourceRoot else null);

and it seems to do the job. With that fix I'm hitting the same problem as above in my packages that required sourceRoot support.

BTW. I've filled some issues about generate-nix-pkg itself: https://nest.pijul.com/pmeunier/nix-rust/discussions . I wonder if you've seen them.

Last, but not least, using this opportunity I'd like to say that @P-E-Meunier , you are my hero. Awesome work and thank you for reddit comments and pijul!

P-E-Meunier · 2017-11-03T06:48:49Z

@dpc, I've seen your issues on the Nest, thanks a lot for them.

In order to use mkRustCrate, you need to cargo install nix-generate-pkg, which translates Cargo.lock files to nix code that uses mkRustCrate.

Example:

$ nix-generate-pkg -o default.nix --src ./ Cargo.lock

This produces a file, default.nix that contains a nix function with a rust derivation as input and a number of derivations as output.

dpc · 2017-11-03T07:07:06Z

@P-E-Meunier You mean generate-nix-pkg? I do have it installed. I even think I know how to use it (hence the issues opened on nest).

Oh. So you're saying that I have to run generate-nix-pkg to generate the file that will use mkRustCrate? I see. Will try that then.

BTW. generate-nix-pkg worked for this project, but generated a line src = ./ that is an error. I had to manually fix it to be src = ./.. No idea why.

Back to trying it out. Will report on results. Thanks!

P-E-Meunier · 2017-11-03T07:10:50Z

BTW. generate-nix-pkg worked for this project, but generated a line src = ./ that is an error. I had to manually fix it to be src = ./.. No idea why.

I think generate-nix-pkg just copies the source from its command line argument to the file. If you call it with generate-nix-pkg --source ./.., it will copy it.

dpc · 2017-11-03T07:35:55Z

If you call it with generate-nix-pkg --source ./.., it will copy it.

Oh, I see.

Anyway, I think I got it.

I've created a simple nix-shell script to try it out (deps.nix is output of generate-nix-pkg):

$ cat shell.nix 
{  pkgs ? (import <nixpkgs> {})}:
let
  deps = import ./deps.nix;
in
pkgs.runCommand "dummy" rec {
  buildInputs = [ (deps.hackeraudit_cli_0_1_0 pkgs.rustc) ];
} ""

It worked beautifully for a moment (dependencies getting build) and then I've hit a problem with crc package:

building path(s) ‘/nix/store/vg4fx2fncg6dqh2wq67bllmnc77l5sna-rust_crc-1.5.0’                                                    
unpacking sources
unpacking source archive /nix/store/1wrgcxrbkm75r40zk9r1h4hjmd49a1ha-crc-1.5.0.tar.gz                                            
source root is crc-1.5.0.tar.gz                                                                                                  
patching sources                                                                                                                 
configuring                                                                                                                      
no configure script, doing nothing
building                                                                                                                          Building src/lib.rs (crc)      
 Running  rustc --crate-name crc src/lib.rs --crate-type lib -C opt-level=3 -C metadata=0fba8bfddb -C extra-filename=-0fba8bfddb 
 --cfg feature="std" --out-dir target/deps --emit=dep-info,link -L dependency=target/deps  --extern build_const=/nix/store/5hd3hz
xgkri5gij6iyh8r0phd3mn0vm8-rust_build_const-0.2.0/libbuild_const-58ad74b56e.rlib --extern crc_core=/nix/store/bdxgjl5pyxmzs53kjmf
hnlkl5wq7jp0b-rust_crc-core-0.1.0/libcrc_core-a43d476d9a.rlib --cap-lints allow
error: couldn't read "/tmp/nix-build-rust_crc-1.5.0.drv-0/crc-1.5.0.tar.gz/target/build/crc.out/crc32_constants.rs": No such file
 or directory (os error 2)      
 --> src/crc32.rs:8:1           
  |                             
8 | build_const!("crc32_constants");                            
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this error originates in a macro outside of the current crate

builder for ‘/nix/store/nhixrj3yaszn8lpv54ls14szr6lkl47l-rust_crc-1.5.0.drv’ failed with exit code 101

but I guess it's a problem with built_const! macro, paths etc. Will investigate tomorrow / on the weekend. Thanks for help!

P-E-Meunier · 2017-11-03T08:42:44Z

@dpc I've just pushed a new commit to handle that case.

Mic92 · 2017-11-03T16:20:40Z

pkgs/build-support/rust/rust-utils.nix

+         echo "$boldgreen" "Building $BUILD (${libName})" "$norm"
+         mkdir -p target/build/${crateName}
+         if [ -e target/link_ ]; then
+           rustc --crate-name build_script_build $BUILD --crate-type bin ${rustcOpts} ${crateFeatures} --out-dir target/build/${crateName} --emit=dep-info,link -L dependency=target/deps ${deps} --cap-lints allow $(cat target/link_)


Can you wrap long lines like this for readability?

Mic92 · 2017-11-03T16:21:13Z

pkgs/build-support/rust/rust-utils.nix

+         mkdir -p $OUT_DIR
+         target/build/${crateName}/build_script_build > target/build/${crateName}.opt
+         set +e
+         EXTRA_BUILD=$(grep "^cargo:rustc-flags=" target/build/${crateName}.opt | sed -e "s/cargo:rustc-flags=\(.*\)/\1/")


Why is both grep and sed required here?

Mic92 · 2017-11-03T16:23:13Z

pkgs/build-support/rust/rust-utils.nix

+      norm="$(printf '\033[0m')" #returns to "normal"
+      bold="$(printf '\033[0;1m')" #set bold
+      green="$(printf '\033[0;32m')" #set red
+      boldgreen="$(printf '\033[0;1;32m')" #set bold, and set red.


It is better use tput here. Otherwise it might print garbage if stdout is not a terminal.

I'm trying to do this, but I keep getting the error

tput: No value for $TERM and no -T specified

When I set a TERM to my terminal, I get instead:

tput: terminal attributes: No such device or address

The command I'm trying to use is

echo "`tput setaf 2``tput bold`Building $BUILD (${libName})`tput sgr0`"

Mic92 · 2017-11-03T16:27:01Z

pkgs/build-support/rust/rust-utils.nix

+
+let buildCrate = { crateName, crateVersion, dependencies, complete, crateFeatures, libName, build, release, libPath, crateType, metadata, crateBin, finalBins, verboseBuild }:
+
+      let depsDir = builtins.foldl' (deps: dep: deps + " " + dep.out) "" dependencies;


concatStringsSep " " dependencies

Mic92 · 2017-11-03T16:27:12Z

pkgs/build-support/rust/rust-utils.nix

+let buildCrate = { crateName, crateVersion, dependencies, complete, crateFeatures, libName, build, release, libPath, crateType, metadata, crateBin, finalBins, verboseBuild }:
+
+      let depsDir = builtins.foldl' (deps: dep: deps + " " + dep.out) "" dependencies;
+          completeDepsDir = builtins.foldl' (deps: dep: deps + " " + dep.out) "" complete;


same as above.

Mic92 · 2017-11-03T16:30:05Z

pkgs/build-support/rust/rust-utils.nix

+                 " --extern ${extern}=${dep.out}/lib${extern}-${dep.metadata}.rlib"
+              else
+                 " --extern ${extern}=${dep.out}/lib${extern}-${dep.metadata}.so")
+            ) "" dependencies;


foldl' can be here also replaced by concatMapStringsSep " " (dep: ...) dependencies

Mic92 · 2017-11-03T16:31:27Z

pkgs/build-support/rust/rust-utils.nix

+            ) "" dependencies;
+          optLevel = if release then 3 else 0;
+          rustcOpts = (if release then "-C opt-level=3" else "-C debuginfo=2");
+          rustcMeta = "-C metadata=" + metadata + " -C extra-filename=-" + metadata;


rustcMeta = "-C metadata=${metadata} -C extra-filename=-${metadata}";

Mic92 · 2017-11-03T16:32:49Z

pkgs/build-support/rust/rust-utils.nix

+    complete = builtins.foldl' (comp: dep: if lib.lists.any (x: x == comp) dep.complete then comp ++ dep.complete else comp) dependencies dependencies;
+
+    crateFeatures = if crate ? features then
+       builtins.foldl' (features: f: features + " --cfg feature=\\\"${f}\\\"") "" crate.features


Can be also replaced by concatStringsSep.

Mic92 · 2017-11-03T16:40:45Z

pkgs/build-support/rust/rust-utils.nix

+      export CARGO_PKG_NAME=${crateName}
+      export CARGO_PKG_VERSION=${crateVersion}
+      export CARGO_CFG_TARGET_ARCH=$(echo ${buildPlatform.system} | sed -e "s/\([^-]*\)-\([^-]*\)/\1/")
+      export CARGO_CFG_TARGET_OS=$(echo ${buildPlatform.system} | sed -e "s/\([^-]*\)-\([^-]*\)/\2/")


buildPlatform.parsed.kernel.name

Where is the documentation for this? If it doesn't exist, I'd like to add it somewhere.

I found out, while playing the nix-repl:

$ nix-repl Welcome to Nix version 1.11.15. Type :? for help. nix-repl> :l <nixpkgs> Added 7885 variables. nix-repl> buildPlatform.parsed { _type = "system"; abi = { ... }; cpu = { ... }; kernel = { ... }; vendor = { ... }; } nix-repl>buildPlatform.parsed.kernel { _type = "kernel"; execFormat = { ... }; families = { ... }; name = "linux"; }

I think this was merged recently for cross compiling. It comes from lib/systems.

This might belong to the nixpkgs documentation then, located in doc. If you are in hurry we also have a wiki to braindump knowledge: https://nixos.wiki/

Mic92 · 2017-11-03T16:41:07Z

pkgs/build-support/rust/rust-utils.nix

+      BUILD_OUT_DIR=""
+      export CARGO_PKG_NAME=${crateName}
+      export CARGO_PKG_VERSION=${crateVersion}
+      export CARGO_CFG_TARGET_ARCH=$(echo ${buildPlatform.system} | sed -e "s/\([^-]*\)-\([^-]*\)/\1/")


buildPlatform.parsed.cpu.name

Mic92 · 2017-11-03T16:45:41Z

pkgs/build-support/rust/rust-utils.nix

+      export CARGO_MANIFEST_DIR="."
+      export DEBUG="${toString (!release)}"
+      export OPT_LEVEL="${toString optLevel}"
+      export TARGET="${buildPlatform.system}-gnu"


Maybe buildPlatform.config? I have: "x86_64-unknown-linux-gnu"

P-E-Meunier · 2017-11-03T18:59:52Z

Wow, that's a serious review. Thanks a lot!

Mic92 · 2017-11-03T19:04:02Z

@P-E-Meunier sorry, this was slacked too long on my todo list.

Mic92 · 2017-11-03T19:05:17Z

cc @Ericson2314 I guess cross-compilation can be also added later, but maybe you have an opinion on the variables that are passed in.

Mic92 · 2017-11-03T19:07:23Z

pkgs/build-support/rust/rust-utils.nix

+      export DEBUG="${toString (!release)}"
+      export OPT_LEVEL="${toString optLevel}"
+      export TARGET="${buildPlatform.system}-gnu"
+      export HOST="${buildPlatform.system}-gnu"


buildPlatform.config These variables will change later for cross compilation.

grahamc · 2017-11-30T13:20:24Z

doc/languages-frameworks/rust.md

+hello_0_1_0.override { crateOverrides = overrides; }
+```
+
+Here, `crateOverrides` is expected to be a attribute set, where the


Nit: "an attribute set"

grahamc · 2017-11-30T13:22:24Z

pkgs/build-support/rust/defaultCrateOverrides.nix

+
+{
+  libsqlite3-sys = attrs: { buildInputs = [ pkgconfig sqlite ] ++ (attrs.buildInputs or []); };
+  openssl-sys = attrs: { buildInputs = [ pkgconfig openssl ] ++ (attrs.buildInputs or []); };


Whatever format we start with in this file will be likely followed blindly until it gets way out of hand. Can you reformat these to be multiple lines? Example:

libsqlite3-sys = attrs: { buildInputs = [ pkgconfig sqlite ] ++ (attrs.buildInputs or []); };

The single line looks more amenable to reading imho, easy to copy/paste a line, move it up and down in alphabetical order using an editor. Also this file could easily get big much like all-packages.nix, so keeping it one liners helps. 2cw

I will not become this big. Most package won't need overriding.
Our defaultGemConfig file is only 342 lines long. Haskell overrides are in the same size magnitude. Having a long single line makes diffs hard to read.

well okay then, if other language level pkg managers use a similar indentation convention then best to stick with it, but at least do this after the merge?

grahamc · 2017-11-30T13:27:39Z

pkgs/build-support/rust/rust-utils.nix

+          version = lib.splitString "." (lib.head version_);
+          authors = lib.concatStringsSep ":" crateAuthors;
+      in ''
+      norm=""


I think it is a bit scary to have a giant set of complex shell scripts embedded in to a .nix file. What would it take to move the shell scripts in to dedicated files, and reference them from here? Then, we can easily use static analysis to help improve / understand them later on.

I tend to agree, but the shell script uses lots of parameters that are nix variables, and some parts are even of the form ${optionalString …}. I guess the way to separate that script would be to create bash functions, but these are harder to read and get right than the Nix code we currently use.

Since I've never done it before, this might as well come from a big misunderstanding of what you meant, so please correct me if I'm wrong.

I agree with @P-E-Meunier that we by not embedding shell in nix we loose useful nix features.

buildCrate could become its own nix file though.

I'm working on a patch to split the shell script into a separate file. Not all of the shell code will transfer, but I think I can get most, and reduce the nix file to just initializing env vars, sourcing the shell script, and running a start_build() shell function or something. At the very least, it'll be something concrete to review and compare.

Okay. Initial patch is drafted. The resulting rust-utils.nix [1] and shell script [2] are available for viewing.

[1]: https://nest.pijul.com/boxofrox/nix-rust:master/8ce71bef4766c2439602
[2]: https://nest.pijul.com/boxofrox/nix-rust:master/289f899c9c9f6d041d

Or if nest is down, here's a gist [3] with the two files.

[3]: https://gist.github.com/boxofrox/7285293d9a552dbf98c421f41838e7ea

@P-E-Meunier, @boxofrox's work looks great, are you keen to use it?

grahamc

Looking pretty good to me. I'm giving it a test with ofborg and will file my feedback on that shortly. I'm a bit concerned about the big shell script being inside the .nix file, that makes it pretty hard to grok and edit later. If possible, I'd like to see that moved to its own file.

grahamc · 2017-12-01T13:17:19Z

When Ibuild carnix, I now get weird output:

grahamc@Morbo> nix-build . -A carnix --check                                                                         ~/projects/nixpkgs
checking path(s) ‘/nix/store/gbsh4sa72bvsmx4sdn3kghwg7hkbinkd-rust_carnix-0.4.14’
unpacking sources
unpacking source archive /nix/store/m9k3s78r7ckrsyymxmkn8a8nw8i7752y-rust
source root is rust
patching sources
configuring
no configure script, doing nothing
building
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/gbsh4sa72bvsmx4sdn3kghwg7hkbinkd-rust_carnix-0.4.14
stripping (with flags -S) in /nix/store/gbsh4sa72bvsmx4sdn3kghwg7hkbinkd-rust_carnix-0.4.14/lib 
patching script interpreter paths in /nix/store/gbsh4sa72bvsmx4sdn3kghwg7hkbinkd-rust_carnix-0.4.14
checking for references to /tmp/nix-build-rust_carnix-0.4.14.drv-0 in /nix/store/gbsh4sa72bvsmx4sdn3kghwg7hkbinkd-rust_carnix-0.4.14...
/nix/store/gbsh4sa72bvsmx4sdn3kghwg7hkbinkd-rust_carnix-0.4.14


$ tree result
result
└── lib
    └── link

1 directory, 1 file


$ cat result/lib/link 
-L native=/nix/store/k8w14fl6hg9mphj1dks2ns1p5pr011mz-sqlite-3.21.0/lib
-L native=/nix/store/xfnqp5fvcnwvgfb6jn679smlgd81rfcp-rust_backtrace-sys-0.1.16/lib/backtrace-sys.out/.libs
-l sqlite3
-l static=backtrace

Mic92 · 2017-12-05T11:39:50Z

pkgs/build-support/rust/carnix.nix

-  backtrace_sys_0_1_16 = backtrace_sys_0_1_16_ {
+      ++ (if kernel == "windows" then [ dbghelp_sys_0_2_0 kernel32_sys_0_2_2 winapi_0_2_8 ]
+      ++ (if lib.lists.any (x: x == "dbghelp-sys") features then [dbghelp_sys_0_2_0] else [])      ++ (if lib.lists.any (x: x == "kernel32-sys") features then [kernel32_sys_0_2_2] else [])      ++ (if lib.lists.any (x: x == "winapi") features then [winapi_0_2_8] else []) else []);
+    features = mkFeatures backtrace_0_3_4_features;


I have not yet understood the purpose of this function. What does it compute exactly?

Previously, Carnix was resolving the dependencies itself. This is not only redundant with what Nix can do, it can also become wrong when some features of some dependencies are enabled only on some platforms (a problem detected by @grahamc).

I'm now using the following trick to resolve features: each package A that wants feature f from dependency B adds the following line to the "function calls" part of the file:

B."f".from_A = true;

Then, mkFeatures aggregates all such declarations and decides whether "f" should be enabled on package B. Sometimes, feature requests can get more complicated and include if statements about the platform, or the activation of another feature.

The "default" feature is trickier, since it is enabled if either no dependent package mentions it, or at least one doesn't want "use-default-features".

Is this equivalent to the following code?

{ crate_a = buildRustCrate { features = ["foo"]; # if "foo" would be a default feature }; crate_b = { dependencies = [ (crate_a.override { features = ["foo" "bar"];} ) # if crate_b has requested "bar" in addition ]; }; }

FlorentBecker · 2017-12-05T13:42:52Z

Should we merge this and continue working on it in master? It would at least make contributions by others than @P-E-Meunier easier.

P-E-Meunier · 2017-12-05T15:08:16Z

I'm ok with merging.

grahamc

I'd say we merge it.

grahamc · 2017-12-09T03:47:47Z

@P-E-Meunier can we do some 1:1 time on IRC to sort out some issues I'm having with this? I'd like to get it merged soon.

sjmackenzie · 2017-12-10T10:18:11Z

Could we at least merge this now so that others can start work on it?

sjmackenzie · 2017-12-12T11:34:11Z

Kudos @P-E-Meunier - thank you.

ben0x539 · 2017-12-12T18:55:35Z

Is there a working link to an issue tracker for carnix? https://crates.io/crates/carnix links to https://nest.pijul.com/pmeunier/carnix which gives me a "Not found".

P-E-Meunier · 2017-12-12T18:58:52Z

The link is actually https://nest.pijul.com/pmeunier/nix-rust

grahamc · 2017-12-13T01:50:10Z

Thank you, everyone, for getting this reviewed and merged. Thank you, @P-E-Meunier for authoring!

* bemenu: init at 2017-02-14 * velox: 2015-11-03 -> 2017-07-04 * orbment, velox: don't expose subprojects the development of orbment and velox got stuck their subprojects (bemenu, dmenu-wayland, st-wayland) don't work correctly outside of parent projects so hide them to not confuse people swc and wld libraries are unpopular and unlike wlc are not used by anything except velox * pythonPackages.pydbus: init at 0.6.0 * way-cooler: 0.5.2 -> 0.6.2 * nixos/way-cooler: add module * dconf module: use for wayland non-invasive approach for #31293 see discussion at #32210 * sway: embed LD_LIBRARY_PATH for #32755 * way-cooler: switch from buildRustPackage to buildRustCrate #31150

P-E-Meunier mentioned this pull request Nov 2, 2017

Introducing mkRustCrate #24991

Closed

7 tasks

P-E-Meunier added 2 commits November 2, 2017 21:14

mkRustCrate in all-packages.nix

7979239

GrahamcOfBorg added 10.rebuild-darwin: 0 10.rebuild-linux: 0 labels Nov 2, 2017

Handling packages that don't have a "build=" in their Cargo.toml

2d85124

Mic92 reviewed Nov 3, 2017

View reviewed changes

grahamc reviewed Nov 30, 2017

View reviewed changes

Documentation with examples that compile

c21a241

grahamc reviewed Nov 30, 2017

View reviewed changes

Carnix 0.4.14

59d16ef

Carnix src was wrong

7d7fe21

dezgeg mentioned this pull request Dec 4, 2017

Build cargo-vendor from source #32254

Closed

Carnix 0.5, including a new way to resolve features

fc84be3

GrahamcOfBorg added 10.rebuild-linux: 0 and removed 10.rebuild-linux: 1-10 labels Dec 5, 2017

Mic92 reviewed Dec 5, 2017

View reviewed changes

grahamc approved these changes Dec 8, 2017

View reviewed changes

Explain argument forwarding

1cd1fca

GrahamcOfBorg added 10.rebuild-linux: 1-10 and removed 10.rebuild-linux: 0 labels Dec 11, 2017

Mic92 added 3 commits December 12, 2017 04:29

rename rust-utils to build-rust-crate

cd0f359

rename defaultCrateOverrides to default-crate-overrides

bf70097

doc/rust: update documentation to reflect latest carnix

f84ad34

Mic92 closed this in 4348b7f Dec 12, 2017


		let buildCrate = { crateName, crateVersion, dependencies, complete, crateFeatures, libName, build, release, libPath, crateType, metadata, crateBin, finalBins, verboseBuild }:

		let depsDir = builtins.foldl' (deps: dep: deps + " " + dep.out) "" dependencies;

Reintroducing mkRustCrate #31150

Reintroducing mkRustCrate #31150

Conversation

P-E-Meunier commented Nov 2, 2017 • edited

Motivation for this change

Things done

P-E-Meunier commented Nov 2, 2017

nyarly commented Nov 2, 2017

Ralith commented Nov 3, 2017

dpc commented Nov 3, 2017 • edited

P-E-Meunier commented Nov 3, 2017

dpc commented Nov 3, 2017

P-E-Meunier commented Nov 3, 2017

dpc commented Nov 3, 2017 • edited

P-E-Meunier commented Nov 3, 2017

Mic92 Nov 3, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mic92 Nov 3, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mic92 Nov 3, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

P-E-Meunier commented Nov 3, 2017

Mic92 commented Nov 3, 2017

Mic92 commented Nov 3, 2017

Mic92 Nov 3, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sjmackenzie Nov 30, 2017 • edited

Choose a reason for hiding this comment

Mic92 Nov 30, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mic92 Dec 1, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

boxofrox Dec 1, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grahamc left a comment

Choose a reason for hiding this comment

grahamc commented Dec 1, 2017

Mic92 Dec 5, 2017 • edited

Choose a reason for hiding this comment

P-E-Meunier Dec 5, 2017 • edited

Choose a reason for hiding this comment

Mic92 Dec 10, 2017 • edited

Choose a reason for hiding this comment

FlorentBecker commented Dec 5, 2017 • edited

P-E-Meunier commented Dec 5, 2017

grahamc left a comment

Choose a reason for hiding this comment

grahamc commented Dec 9, 2017

sjmackenzie commented Dec 10, 2017

sjmackenzie commented Dec 12, 2017

ben0x539 commented Dec 12, 2017

P-E-Meunier commented Dec 12, 2017

grahamc commented Dec 13, 2017

P-E-Meunier commented Nov 2, 2017 •

edited

dpc commented Nov 3, 2017 •

edited

dpc commented Nov 3, 2017 •

edited

Mic92 Nov 3, 2017 •

edited

Mic92 Nov 3, 2017 •

edited

Mic92 Nov 3, 2017 •

edited

Mic92 Nov 3, 2017 •

edited

sjmackenzie Nov 30, 2017 •

edited

Mic92 Nov 30, 2017 •

edited

Mic92 Dec 1, 2017 •

edited

boxofrox Dec 1, 2017 •

edited

Mic92 Dec 5, 2017 •

edited

P-E-Meunier Dec 5, 2017 •

edited

Mic92 Dec 10, 2017 •

edited

FlorentBecker commented Dec 5, 2017 •

edited