Cargo: providing artifacts (for artifact dependencies) via build.rs by joshtriplett · Pull Request #3035 · rust-lang/rfcs (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation9 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
This RFC grew out of a discussion on the artifact dependencies RFC. As an extension of
that RFC, some crates will want to supply artifacts via build.rs, such
as by building them from sources or passing through an artifact
dependency from a different crate. Some crates may also want to make
decisions about how to supply a binary based on feature flags or
detection.
This RFC introduces a mechanism to do so, via targets withmanual = true. For such targets, Cargo expects build.rs to supply
the target, by placing it in a directory specified by Cargo.
Relevant to the Cargo team, which will review and decide on the RFC.
label
Cargo manual targets Cargo: providing artifacts (for artifact dependencies) via build.rs
CARGO_ARTIFACT_DIR would be very useful for more things than just binaries (I've asked for it in rust-lang/cargo#5457). Crates currently can't build things like man pages or resource files to be bundled later. Having a known location for all build products would be great.
If a script is building dynamic library, what should it set as the rpath for the library? Can Cargo help with this?
Currently this is undefined/ignored in Cargo and makes dylibs painful to use when dylibs use a relative rpath, because Cargo isn't aware of it, so things like test/bench executables that are in a different directory than build products look for dylibs in a wrong place.
@kornelski I would love to have a mechanism like this for other kinds of artifacts, including manpages or completions. However, I'd prefer to keep that separate from this RFC. After this RFC goes through, I'd be happy to collaborate on an extension to other kinds of artifacts.
I also think it might make sense for Cargo to export information about other profile options. That seems like it'd be a good item for an RFC as well.
(Current status of this: waiting for a completed implementation of baseline artifact dependencies before moving forwards.)
@rfcbot postpone
I propose we postpone this until we have rust-lang/cargo#9096 stabilized so we have a better view of where things are at.
Team member @epage has proposed to postpone this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
This comment was marked as resolved.
🔔 This is now entering its final comment period, as per the review above. 🔔
The final comment period, with a disposition to postpone, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This is now postponed.