How to retrieve build artifact paths? #3757
Comments
|
Top level artifacts should always show up in predictable locations (if you're controlling the variables above). Otherwise |
|
Oh right, I completely forgot about that option. However I would still like the possibility to display warnings and error messages in text form. Are these text messages easy to reconstruct from JSON or is some information lost? EDIT: I'm only interested in top-level binary artifacts, but I do not have control over the variables mentioned. |
|
Yeah unfortunately right now once json messages are emitted there's no way to get back the original rendering (currently). It's come up before though and we'd definitely like to be able to enable it! Also yeah that sounds like a reasonable way to learn about the top-level crate, I believe. |
|
Would it be possible to have |
|
Perhaps yeah, Cargo doesn't currently try to pick which lines are json and which aren't, but we could perhaps soup up the logic. (this'd require changes to the compiler) |
Fixed in #3752 |
|
Yeah, thanks, this works fine for now. The only problem I still have is with |
|
Actually, having fought with creating a transparent wrapper around cargo for some time now, I can safely say that this is not a solution. There needs to be a better way to obtain the final artifact paths, without butchering all of the rustc output. The only two solutions I can think of is creating a wrapper around rustc that filters out the |
There's more work to be done here, but it's a start. Honestly, adding miniserde just to parse out the Cargo metadata seems way more difficult than it should be to get an accurate list of the binary artifacts for the project. There is an unstable `--out-dir` feature to copy artifacts for you after building, but it hasn't stabilized over the past couple of years. Not ideal. See: - rust-lang/cargo#3757 - rust-lang/cargo#6790 (comment) - matklad/cargo-xtask#3
There's more work to be done here, but it's a start. Honestly, adding miniserde just to parse out the Cargo metadata seems way more difficult than it should be to get an accurate list of the binary artifacts for the project. There is an unstable `--out-dir` feature to copy artifacts for you after building, but it hasn't stabilized over the past couple of years. Not ideal. See: - rust-lang/cargo#3757 - rust-lang/cargo#6790 (comment) - matklad/cargo-xtask#3
There's more work to be done here, but it's a start. Honestly, adding miniserde just to parse out the Cargo metadata seems way more difficult than it should be to get an accurate list of the binary artifacts for the project. There is an unstable `--out-dir` feature to copy artifacts for you after building, but it hasn't stabilized over the past couple of years. Not ideal. See: - rust-lang/cargo#3757 - rust-lang/cargo#6790 (comment) - matklad/cargo-xtask#3
There's more work to be done here, but it's a start. Honestly, adding miniserde just to parse out the Cargo metadata seems way more difficult than it should be to get an accurate list of the binary artifacts for the project. There is an unstable `--out-dir` feature to copy artifacts for you after building, but it hasn't stabilized over the past couple of years. Not ideal. See: - rust-lang/cargo#3757 - rust-lang/cargo#6790 (comment) - matklad/cargo-xtask#3
How do I determine which artifacts cargo produced and where? The used target directory depends on multiple environment variables (e.g.
CARGO_TARGETDIR), configuration settings (e.g.build.target-dirandbuild.target), command-line arguments (--target,--release). Not to mention it gets even more complicated when the package is part of a workspace. Of course it also depends on settings insideCargo.tomlbut at least for these settings there's thecargo metadatacommand.Now my question is if there is any easy way to know which artifacts were produced and where? Or do I have to parse all of the stuff above and mimic undocumented implementation details of how cargo determines output locations and names? If the latter is the case, then this greatly complicates integrating cargo into any other build system. For my specific use case, I need to provide a post-build step that is project-agnostic, i.e. all of the variables above might change. How should I go about?
The text was updated successfully, but these errors were encountered: