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

Install: add a bindir flag or similar #10748

Open
1480c1 opened this issue Jun 11, 2022 · 3 comments
Open

Install: add a bindir flag or similar #10748

1480c1 opened this issue Jun 11, 2022 · 3 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-install S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.

Comments

@1480c1
Copy link

1480c1 commented Jun 11, 2022

Problem

Currently, "bin" is always suffixed onto the root, meaning it's really hard when trying to deal with installing binaries from a project into a separate directly, that's not specifically bin (for example, if I have a video related tool, I might install it into $root/bin-video, and $root/bin-audio for an audio related tool, and so on).

I currently have to do something like

cargo build --release ...
install -D -p target/*/release/*.exe "$root/bin-video"

and that's not very desirable and very fragile.

I tried looking to see if a similar issue existed, but could not find anything yet.

Proposed Solution

One solution would be to add a flag to cargo install that would take a relative path to --root, and if not provided, default to "bin", and that would be used in the below code locations instead of the current contant strings.

let dst = root.join("bin").into_path_unlocked();

let dst = root.join("bin").into_path_unlocked();

let dst = self.root.join("bin").into_path_unlocked();

So, something like --root /mycustomprefix --bindir bin-video would install the executables into /mycustomprefix/bin-video instead of /mycustomprefix/bin

Notes

No response

@1480c1 1480c1 added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Jun 11, 2022
@weihanglo
Copy link
Member

One purpose of cargo having --root option 1 is for tracking installed binaries. Unfortunately, the current version of InstallInfo 2 doesn't record installed path. We might need to come up with a compatible solution if we go the way you proposed.

At this moment, you can use JSON message format with jq to get a stable path for your binaries, such like

# Use at your own risk
cargo build --message-format=json -q | jq -r 'select(.target.kind[0] == "bin") | .executable'

Footnotes

  1. https://doc.rust-lang.org/cargo/reference/config.html#installroot

  2. https://github.com/rust-lang/cargo/blob/6b8e1922261bbed1894bf40069fb2d5dc8d62fb0/src/cargo/ops/common_for_install_and_uninstall.rs#L60-L85

@weihanglo
Copy link
Member

If you are willing to share with us, we would like to know more about the practical use case for separate bin dirs.

  • What is the reason behind this?
    • Why those binaries can't put altogether?
    • Is it about distributions or permission controls?
  • Do you need to track installed binaries?

Given it sounds like a specialized use case, it's more likely to move forward if more details are provided. Thank you.

@weihanglo weihanglo added the S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. label May 24, 2023
@epage
Copy link
Contributor

epage commented Nov 6, 2023

https://internals.rust-lang.org/t/pre-rfc-split-cargo-home/19747 might offer a way to workaround this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-install S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.
Projects
None yet
Development

No branches or pull requests

3 participants