Skip to content
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

Open
antifuchs opened this issue Nov 25, 2020 · 5 comments
Open

How do you select --bin targets? #127

antifuchs opened this issue Nov 25, 2020 · 5 comments

Comments

@antifuchs
Copy link

antifuchs commented Nov 25, 2020

I've got a program here that has two [[bin]] targets in its Cargo.lock: deploy and activate, and only one of them, deploy, can build on macOS (both of them build on Linux); so I have to run cargo 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:

        darwinOptions = pkgs.lib.optionalAttrs stdenv.isDarwin {
          cargoBuildOptions = opts: opts ++ [ "--bin" "deploy" ]; # The "activate" binary is linux-only.
        }

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?

antifuchs added a commit to antifuchs/deploy-rs that referenced this issue Nov 25, 2020
* 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.
notgne2 pushed a commit to serokell/deploy-rs that referenced this issue Nov 25, 2020
* 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.
@nmattia
Copy link
Collaborator

nmattia commented Nov 30, 2020

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 (override, overrideMain) we could allow overriding some naersk options as well - which, IIUC, is what you suggest! Let me know if you have some UX in mind.

@theduke
Copy link

theduke commented Apr 23, 2021

I'm also running into this.

Finding a solution here would be great.

@BrianHicks
Copy link

BrianHicks commented Apr 25, 2022

I'm getting around this for now by setting copyBinsFilter:

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 targets?)

@tiagolobocastro
Copy link

Hi, any update on this? Would be really nice to be able to build single binaries :)

@Patryk27
Copy link
Contributor

Hi,

No progress has been done on this yet - I think adding something like cargoBuildOptionsButOnlyForTheMainDerivationNotTheDependenciesOne should be pretty straightforward, so I'll try tackling it within a few days 🙂

suzukidavid added a commit to suzukidavid/rust-deploy that referenced this issue Dec 4, 2022
* 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.
gshipunov added a commit to tlm-solutions/lofi that referenced this issue Feb 7, 2023
jeremyschlatter added a commit to jeremyschlatter/env that referenced this issue Jun 15, 2023
tommy725 added a commit to tommy725/rust-deploy that referenced this issue Aug 9, 2023
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants