`explain` only shows one feature set for `target` and one for `host`, so why is the crate in the workspace hack crate?

[carols10cents]

I'm using cargo-hakari 0.9.10, with the new explain feature (🎉 ), but I'm still confused about why the regex-syntax crate is in my project's workspace hack crate generated by cargo-hakari, and explain isn't helping (or I don't understand what it's telling me).

I've put a small-ish reproduction of this on this branch in this repo: https://github.com/integer32llc/hakari-repro/tree/regex-syntax

Crate "hello" has a dependency on croaring, which has bindgen as a build dependency, which has regex as a dependency in two places, and each place has regex-syntax as a dependency.

Relevant part of `cargo tree --no-dedupe` output

hello v0.1.0 (/Users/carolnichols/rust/hakari-repro/hello)
├── croaring v0.5.1
│   ├── croaring-sys v0.5.1
│   │   [build-dependencies]
│   │   ├── bindgen v0.59.2
│   │   │   ├── env_logger v0.9.0
│   │   │   │   ├── regex v1.5.4
│   │   │   │   │   └── regex-syntax v0.6.25
│   │   │   ├── regex v1.5.4
│   │   │   │   └── regex-syntax v0.6.25

Crate "world" has a dependency on regex-automata, which has regex-syntax as a dependency.

Relevant part of `cargo tree --no-dedupe` output

world v0.1.0 (/Users/carolnichols/rust/hakari-repro/world)
├── regex-automata v0.1.10
│   └── regex-syntax v0.6.25

cargo hakari generate has put regex-syntax in the workspace-hack crate under both regular and build dependencies:

[dependencies]
regex-syntax = { version = "0.6", features = ["unicode", "unicode-age", "unicode-bool", "unicode-case", "unicode-gencat", "unicode-perl", "unicode-script", "unicode-segment"] }

[build-dependencies]
regex-syntax = { version = "0.6", features = ["unicode", "unicode-age", "unicode-bool", "unicode-case", "unicode-gencat", "unicode-perl", "unicode-script", "unicode-segment"] }

When I run cargo hakari explain regex-syntax, I get this output:

info:
  package  |  include dev?  features  platform

on the target platform, feature set default, unicode, unicode-age, unicode-bool, unicode-case, unicode-gencat, unicode-perl, unicode-script, unicode-segment was built by:

   world   |       *           *         *

on the host platform, feature set unicode, unicode-age, unicode-bool, unicode-case, unicode-gencat, unicode-perl, unicode-script, unicode-segment was built by:

   hello   |       *           *         *

Based on the crate listings, I assume the "on the target platform" section is talking about the regular dependency and "on the host platform" is talking about the build dependency.

Based on my understanding of cargo-hakari, I expected at least 2 different feature sets to appear here for both the target section and the host section-- but there's only one set of features.

So I still don't know why cargo-hakari has put regex-syntax into the workspace hack crate, and cargo hakari explain isn't telling me in a way I can understand :)

I very much appreciate your help, thank you!!!

[sunshowers]

Ahh yeah, that is the "unify across target and host platforms" feature which ensures that a dependency used across the target and host platforms is built just once.

https://docs.rs/cargo-hakari/0.9.11/cargo_hakari/config/index.html#unify-target-host

You can turn it off in the config by setting

unify-target-host = "none"

but I would generally recommend keeping it on, it sped up build times significantly when I was implementing it

[carols10cents]

Ahaaaa I see. So even though the build deps and regular deps aren't unified in one section in the workspace hack crate because the v2 Cargo resolver doesn't unify features between them (like it does with development and regular dependencies), the workspace hack effectively unifies the feature sets before listing a dependency as both a build and regular dependency, so that the same artifact can be used as the build dep and the regular dep.

Feel free to close this if you'd like, or leave it open as a documentation improvement suggestion: the docs at https://docs.rs/cargo-hakari/latest/cargo_hakari/about/index.html give a nice example in the "What are workspace-hack crates?" but uses all regular dependencies. Then there's this note:

NOTE: This description elides some details around unifying build and dev-dependencies: for more about this, see the documentation for guppy’s CargoResolverVersion.

which links to https://docs.rs/guppy/0.12.4/guppy/graph/cargo/enum.CargoResolverVersion.html, which explains the behavior of the different Cargo resolvers, but doesn't really get into cargo-hakari's behavior around unifying build and regular dependencies.

I think having an additional example with one crate in the workspace having a build dep and the other having a regular dep with different feature sets, and showing what cargo-hakari generates in the workspace hack crate and why in that case, would have helped me a lot to understand.

Thank you again for your quick response! ❤️

[sunshowers]

the workspace hack effectively unifies the feature sets before listing a dependency as both a build and regular dependency, so that the same artifact can be used as the build dep and the regular dep.

Exactly! And there's a further wrinkle: if there are some dependencies that are proc macros, or build deps of others in the workspace, then hakari uses an even more aggressive scheme because the dependencies might be built on either the target or the host platform (or both).

I'll leave this open as a documentation bug -- thanks for the report.