Cargo: providing artifacts (for artifact dependencies) via build.rs

[joshtriplett]

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 with
manual = true. For such targets, Cargo expects build.rs to supply
the target, by placing it in a directory specified by Cargo.

cc @jyn514 @alexcrichton

Rendered

[kornelski]

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.

[kornelski]

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.

[joshtriplett]

@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.

[joshtriplett]

(Current status of this: waiting for a completed implementation of baseline artifact dependencies before moving forwards.)

[epage]

@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.

[rfcbot]

Team member @epage has proposed to postpone this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔