-
Notifications
You must be signed in to change notification settings - Fork 88
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
How do you select --bin
targets?
#127
Comments
* Bump the nixpkgs version to one that ships Rust 1.47, which can produce binaries under macOS 11 (Big Sur). * Use darwin-specific options that let Naersk build the "deploy" binary under macOS. (With a work-around for nix-community/naersk#127, which prevents this from being much more straight-forward). Unfortunately, the "activate" binary can't be built under macOS due to the inotify dependency; that means the best we can do is to run the deploy under macOS, not deploy *to* macOS.
* Add xcbuild as native build input 2 ways & pass --verbose to cargo build * Make "deploy" build on macOS * Bump the nixpkgs version to one that ships Rust 1.47, which can produce binaries under macOS 11 (Big Sur). * Use darwin-specific options that let Naersk build the "deploy" binary under macOS. (With a work-around for nix-community/naersk#127, which prevents this from being much more straight-forward). Unfortunately, the "activate" binary can't be built under macOS due to the inotify dependency; that means the best we can do is to run the deploy under macOS, not deploy *to* macOS.
Hey @antifuchs, I didn't think about this, but yes, that would be nice. We already override some build options for dependencies internally, but we could make this more broadly available. Just as we allow overriding the derivation's attributes ( |
I'm also running into this. Finding a solution here would be great. |
I'm getting around this for now by setting copyBinsFilter = ''
select(.reason == "compiler-artifact" and .executable != null and .profile.test == false and .target.name == "${name}")''; however, this only works because I'm treating it as a packaging thing only—all the targets in my virtual manifest are still getting built (despite setting |
Hi, any update on this? Would be really nice to be able to build single binaries :) |
Hi, No progress has been done on this yet - I think adding something like |
* Add xcbuild as native build input 2 ways & pass --verbose to cargo build * Make "deploy" build on macOS * Bump the nixpkgs version to one that ships Rust 1.47, which can produce binaries under macOS 11 (Big Sur). * Use darwin-specific options that let Naersk build the "deploy" binary under macOS. (With a work-around for nix-community/naersk#127, which prevents this from being much more straight-forward). Unfortunately, the "activate" binary can't be built under macOS due to the inotify dependency; that means the best we can do is to run the deploy under macOS, not deploy *to* macOS.
Because of nix-community/naersk#127
Because of nix-community/naersk#127
* Add xcbuild as native build input 2 ways & pass --verbose to cargo build * Make "deploy" build on macOS * Bump the nixpkgs version to one that ships Rust 1.47, which can produce binaries under macOS 11 (Big Sur). * Use darwin-specific options that let Naersk build the "deploy" binary under macOS. (With a work-around for nix-community/naersk#127, which prevents this from being much more straight-forward). Unfortunately, the "activate" binary can't be built under macOS due to the inotify dependency; that means the best we can do is to run the deploy under macOS, not deploy *to* macOS.
I've got a program here that has two
[[bin]]
targets in its Cargo.lock:deploy
andactivate
, and only one of them,deploy
, can build on macOS (both of them build on Linux); so I have to runcargo build
with--bin deploy
to get the binary output on the command-line, and I would love to do the same in Naersk.I thought that I could achieve victory here by doing:
That, however, causes dependency builds to get the
--bin
option passed as well, which breaks the build; it also feels weird.A work-around for this is to also pass
singleStep = true;
, but that is also un-ideal. (No incremental builds!)What I'd really like here is to have an option in Naersk that lets users select the
--bin
targets to output.Alternatively, it would also be ok to have a way to override the cargo options on dependency builds (defaulting to the overall cargo options function). That way too, we could select the options applying to the "build" of the top-level system, and the options that apply to the system's dependencies.
What do you think?
The text was updated successfully, but these errors were encountered: