How to retrieve build artifact paths?

[Jascha-N]

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-dir and build.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 inside Cargo.toml but at least for these settings there's the cargo metadata command.

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?

[alexcrichton]

Top level artifacts should always show up in predictable locations (if you're controlling the variables above). Otherwise --message-format=json should print out all paths that are compiled

[Jascha-N]

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. cargo does not seem to output the final file names (inside the release/debug folder) but only the artifacts inside the deps folder. But I guess that is alright since it contains the top-level package as well (albeit with a different suffix). To find out which are the top-level artifacts I could match the package_id against the package_id returned by cargo metadata --no-deps. Is this correct?

[alexcrichton]

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.

[Jascha-N]

Would it be possible to have rustc print the original messages in addition to the JSON representation in the same way that cargo does this, i.e. original messages on stderr and JSON on stdout?

[alexcrichton]

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)

[matklad]

cargo does not seem to output the final file names (inside the release/debug folder)

Fixed in #3752

[alexcrichton]

Thanks @matklad!

@Jascha-N is that sufficient now perhaps?

[Jascha-N]

Yeah, thanks, this works fine for now. The only problem I still have is with rustc's messages being in JSON format.

[Jascha-N]

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 --error-format json option if --message-format json was not passed to the cargo wrapper or running cargo twice (the second time with --message-format json and output captured) just to obtain the artifact paths. Neither solution is nice in my opinion.

[matklad]

@Jascha-N I've created #3855 about the problem.