New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
buildRustPackage: add support for non-default bins #80869
Conversation
Some Rust crates can generate multiple executables. In order to build executables other than the default, cargo's `--bin` flag is necessary. This patch adds a `buildBins` parameter to `buildRustPackage` so that these executables may be built.
No objection to the addition but why aren't you just passing `--bins` to
cargo? That would get you all the binaries without having to specify any
names. Another related topic might be creating example executables (as
dedicated output?). Sometimes libraries provide example implementations
that are all one really needs.
|
In my case, I’m trying to package sccache-dist separately from sccache (which is already packaged by someone else). Both sccache and sccache-dist are designed to be used on their own or in conjunction, so I think it makes sense to allow these to be installed independently. If I were to use |
On 07:09 23.02.20, Alex Crawford wrote:
In my case, I’m trying to package sccache-dist separately from sccache
(which is already packaged by someone else). Both sccache and
sccache-dist are designed to be used on their own or in conjunction,
so I think it makes sense to allow these to be installed
independently. If I were to use `--bins` in the sccache-dist
derivation, that would cause a conflict with the sccache derivation
(both would install `sccache`).
Wow. I wasn't aware that `cargo` would handle it like that. Looking at
the `Cargo.toml` of the project it seems like it should be able to build
both binaries (with different names):
```toml
[[bin]]
name = "sccache"
[[bin]]
name = "sccache-dist"
required-features = ["dist-server"]
```
In that case that flag actually makes sense but probably is also worth
an upstream (as in cargo) bug. It should just create the `sccache-dist`
bin with the proper name as defined in the `Cargo.toml`.
LGTM 👍
|
Let me clarify. Cargo will build both binaries with the |
On 06:59 24.02.20, Alex Crawford wrote:
Let me clarify. Cargo _will_ build both binaries with the `--bins`
flag (each one will have the respective name specified in Cargo.toml).
The issue is just that if I install the sccache derivation, I won’t be
able to install the (as of yet nonexistent) sccache-dist derivation
(due to both providing `sccache`).
This sounds more like you need a multiple output derivation. You would
move binaries in a dedicated output that users then can select. This has
the benefit of doing the whole dependency compilation only once and not
for every other binary that package might provide.
If you then need another version of `sccache-dist` you would override
the source (as usual) and just pick the `.dist` output.
That would be something you do during `installPhase`. You move some
binaries to another output.
```
…
buildRustPackage {
…
outputs = [ "out" "dist" ];
postInstall = ''
moveToOutput "bin/sccache-dist" "$dist"
'';
}
```
In `pkgs/top-level/all-packages.nix` you
would then just refer to them like this:
```
sccache = pkgs.callPackage ./somewhere.nix {};
sccache-dist = sccache.dist;
```
In your system configuration you would then just say
```
environment.systemPackages = [ pkgs.sccache.dist ];
```
to only install the `dist` output.
|
Ah, interesting. That does sound more like what I’m after. With that approach, this PR doesn’t seem necessary. Thanks for your review! |
Motivation for this change
In order to eventually package sccache-dist, I need to plumb through the
--bin
flag tocargo build
(i.e.cargo build --bin sccache-dist
).Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)