oxidecomputer / omicron

Omicron: Oxide control plane
Mozilla Public License 2.0
244 stars 36 forks source link

cargo doc reports a filename collision between the `oximeter` bin target and the separate `oximeter` lib target #5976

Open iliana opened 2 months ago

iliana commented 2 months ago

I think we hadn't noticed this before because we had been running cargo doc without --no-deps, so it got lost in all the duplicate targets from having several dependencies at different versions:

+ ptime -m cargo doc --workspace --no-deps
warning: output filename collision.
The bin target `oximeter` in package `oximeter-collector v0.1.0 (/work/oxidecomputer/omicron/oximeter/collector)`
has the same output filename as the lib target `oximeter` in package `oximeter v0.1.0 (/work/oxidecomputer/omicron/oximeter/oximeter)`.
Colliding filename is: /work/oxidecomputer/omicron/target/doc/oximeter/index.html
The targets should have unique names.
This is a known bug where multiple crates with the same name use
the same path; see <https://github.com/rust-lang/cargo/issues/6313>.

(output wrapped for readability)

Specifically, having a crate named "oximeter" and having a bin target in a separate package (oximeter-collector) called "oximeter" is triggering an output filename collision warning while building documentation. It's unclear whether this matters long-term; Cargo can't reasonably make this a hard error in the future until cargo doc is capable of supporting multiple crates with the same names (at different versions), at which point they might also support this particular issue.

Options:

  1. Do nothing and ignore the warning.
  2. Rename the "oximeter" crate; this has the effect of needing to also fix the crate name in every other repo that uses this library, which is painful.
  3. Rename the "oximeter" binary; this is self-contained to Omicron.
  4. Possibly hack around the issue by renaming the lib target without renaming the crate by explicitly listing a [lib] section with a different name.

cc @bnaecker

davepacheco commented 2 months ago

Would it solve this problem to disable doc builds for the binary? We already do this for some binaries (for outdated reasons, it looks like): https://github.com/oxidecomputer/omicron/blob/a14b41a2342fc3e8dcb2abf777a82289055e39c8/dev-tools/omdb/Cargo.toml#L69-L73

iliana commented 2 months ago

Oh, I didn't know you could do that! That probably makes the most sense.