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

better support for generation and installation of associated files #13663

Open
lolbinarycat opened this issue Mar 27, 2024 · 4 comments
Open
Labels
A-build-scripts Area: build.rs scripts C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@lolbinarycat
Copy link

lolbinarycat commented Mar 27, 2024

Problem

i was trying to create an idiomatic template that uses clap_complete within build.rs in order to generate and install shell completions, when i realized it is basically impossible.

because cargo install only installs binaries, you have to use a Makefile, which is fine, but there's a problem:

  • build.rs is only supposed to create files under $OUT_DIR
  • the value of $OUT_DIR is not easily accessible to outside programs
  • the makefile needs to know where the files are in order to install them

Proposed Solution

  1. add a mechanism for the main crate (i.e. the one the user said to build, not any of its dependancies) built to produce outputs in $CARGO_TARGET_DIR (or a fixed subdir thereof, such as target/release/aux)
  2. (low priority) add a cargo::install instruction that allows directing cargo install to install files relative to a configured prefix (eg. .local, /usr, or /usr/local). using cargo::install=$OUT_DIR/CMDNAME.bash=share/bash/bash-completions/completions/CMDNAME would install the completion in the specified completion dir. (see Support installing manpages (and potentially other files) #2729)

Notes

No response

@lolbinarycat lolbinarycat added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Mar 27, 2024
@epage
Copy link
Contributor

epage commented Mar 27, 2024

Going to close in favor of #2729. While there might be differences in solution, the root problem is the same and it would be good to focus the conversation on how to solve the problem in one place with one coherent solution, regardless of what is initially mentioned in the original issue.

If there is a reason for us to keep this open separately, let us know!

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Mar 27, 2024
@lolbinarycat
Copy link
Author

@epage that issue is almost completely orthogonal. if i had decided to just not mention cargo install, there would be no overlap.

my main issue is with external tools being unable to easily access files created by build scripts.

@epage
Copy link
Contributor

epage commented Mar 27, 2024

Made an edit to the issue to try to clarify that. Is that right?

If I'm understanding the main issue, it is one of the use cases brought up in #9661, see #9661 (comment) for the summary of the discussion, particularly "Staging files for the --out-dir so they are next to the cargo-built final artifacts". Is that right?

@epage epage reopened this Mar 27, 2024
@lolbinarycat
Copy link
Author

yes, precisely.

i think producing the files in OUT_DIR and having cargo conditionally copy them over is the best solution, it maintains isolation, which is quite important for edge cases like hybrid lib+bin crates that also have a build script that produces shell completions.

@epage epage added A-build-scripts Area: build.rs scripts and removed Command-install labels Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-build-scripts Area: build.rs scripts C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants