"cargo metadata" should contain metadata and extra_filename

[jsgf]

Right now, it's impossible to know what the filename of a generated .rlib for a library crate is.

Most of the path can be derived, except for metadata:

target/<buildmode>/lib<cratename>-<metadata>.rlib

• buildmode - debug or release
• cratename - crate name, with '-' mapped to '_'
• metadata - ???

It would be useful if cargo metadata included either the metadata portion, or the complete generated lib name (but not the whole path, since that's build-mode dependent, and metadata doesn't have the build mode - and presumably because its invariant to build mode?).

This is for integration with external build tools, so they can use cargo to generate the .rlib, then use it as part of another build process.

[matklad]

cc #1924

[matklad]

I don't know how exactly mixing metadata into the file name works, but looks like it is produced during a build to disambiguate possibly identically named artifacts. So perhaps this info should be not the part of cargo metadata command, but a part of cargo build command? That is, cargo build would output the names of the artifacts it would have produced. This has a nice property: if you have a library name, than it must have been build and is fresh.

[jsgf]

I had thought about that, but I'd prefer to decouple build from getting the metadata. I'm actually going to be building the crates multiple times (for different versions of libc/gcc), but I want to use a single set of metadata to describe those builds (since they're all logically the same entity).

My understanding of the code is that the metadata is only dependent on the package name, the registry it came from, its version, and a salt-like thing indicating its use (lib, test, etc), so it should work out. It's just that the use-salt is localized to the build path and not shared by the cargo metadata code, so if the latter tries to compute the metadata it comes up with the wrong result. If I hack around that, then it still fails when using registry remapping, as it seems that one or the other is computing the metadata from the remapped registry name rather than the canonical one (I'm not sure which is correct; it doesn't really matter so long as they're consistent).

[jsgf]

Ah, I can get per-target metadata which seems to be what I want. So I just need to work out the registry remapping issue.

[alexcrichton]

Agreed that this should be part of cargo metadata, but as soon as cargo build produces JSON we should also emit it there!

[jsgf]

Yes, cargo build could emit the complete path to the built artifact, whereas cargo metadata can't do that because the full path is build-mode dependent. Is there a problem with applying this PR now, and handling build later?

[alexcrichton]

Oh yeah handing cargo build is totally fine to handle later.

[carols10cents]

I believe this was fixed in #3319. Please reopen if I'm mistaken! Thank you!

[oxalica]

Hit this issue in 1.64.0. It's NOT resolved by #3319 and should be re-opened.

The problem is caused by the suggestion #3319 (comment) from @jsgf, we special case the rlib and bin to the linked path debug/* instead of consistent deps/<name>-<meta>.<ext>. Thus we print no extra_filename information.

Currently cargo build --message-format=json gives me this, which contains no extra_filename at all.

{
  "reason": "compiler-message",
  "package_id": "testt 0.1.0 (path+file:///home/oxa/tmp/testt)",
  "manifest_path": "/home/oxa/tmp/testt/Cargo.toml",
  "target": {
    "kind": [
      "bin"
    ],
    "crate_types": [
      "bin"
    ],
    "name": "testt",
    "src_path": "/home/oxa/tmp/testt/src/main.rs",
    "edition": "2021",
    "doc": true,
    "doctest": false,
    "test": true
  },
  "message": {
    "rendered": "error: aborting due to previous error\n\n",
    "children": [],
    "code": null,
    "level": "error",
    "message": "aborting due to previous error",
    "spans": []
  }
}

For rlibs, it is kind of better. But we still need to parse the rmeta path to get that hash.

  "filenames": [
    "/home/oxa/.cache/testt-target/debug/libtestt.rlib",
    "/home/oxa/.cache/testt-target/debug/deps/libtestt-dfaee7c0138c0340.rmeta"
  ],

The extra-filenames (hash part) is important to retrieve all outputs produced by rustc. Especially when we use something like cargo rustc -- --emit=asm, the extra artifacts will be deps/<name>-<extrafilename>.s. The extra-filename is required to correctly retrieve these artifacts. But it's currently not possible for bin targets.