Improve per-platform feature selection.

[sayrer]

This patch should fix #451.

The patch runs cargo-tree to determine which features are enabled on each platform, and then groups them by using vectors of platforms as map keys. It's a lot of code, and there are no tests yet. But I wanted to post this initial effort and get some feedback from the code owners. @illicitonion has already seen this code, but I believe it will be new to @dfreese and @PiotrSikora (who filed the linked issue).

The new file is copyright AgileBits, as this was work for hire for them. They are fine with contributing, and my repo has been public for months.

[sayrer]

I've looked around the examples and the impl/ directory, and I'm not sure where to add this crate: https://github.com/lambda-fairy/rust-errno/blob/main/Cargo.toml

This patch should consolidate the unix and wasi requirements for the libc crate required there.

[dfreese]

Overall, I'm not thrilled by the idea of having to invoke and parse cargo-tree for every platform, but cargo isn't giving good alternatives.

I'm generally supportive of the approach. Are there any other tactics for this in the wild?

[illicitonion]

I'm also generally supportive of the approach given the state of cargo, but sad that there don't seem to be viable alternatives - thanks so much for putting this together and upstreaming it 👍

[sayrer]

It looks like this patch will not fix errno, but it will fix a bunch of related issues with features. I must have another, shorter, patch in my code for the problem in deps.

As for approaches to this problem, I only found two choices: Import cargo as a crate directly, and use its internal resolver implementation (which is pub), or use cargo-tree.

I chose to use cargo-tree, because taking cargo internals as a dependency seemed even less appealing than what I have here. I haven't seen anyone else solve this problem in the wild, and I definitely looked before writing this code.

[leebenson]

Very much looking forward to this landing!

[dfreese]

Sorry, missed that you had also responded to review comments as well. I'm good with this as long as the new code can be covered by unit tests where reasonable.

The copyright/license notice probably needs to be updated, but I'm not entirely sure what needs to happen given the CLA. @hlopko do you have any familiarity with that?

[sayrer]

I have some better tests coming, and I still need to go through the ? early exits and give them some messages.

[dfreese]

I have some better tests coming, and I still need to go through the ? early exits and give them some messages.

Sounds good. Thanks for the update!

[dfreese]

Handful of comments. Generally looks good to me. Thanks for putting all of this together.

Can you rebase to HEAD as well just to make sure no issues have cropped up?

[sayrer]

Will address these, but I think the Dependabot stuff and #482 should go in first. Not in a rush over the weekend.

[sayrer]

OK, I think this is all set.

[dfreese]

Lgtm, one question.

[dfreese]

Great. Thanks. Can you merge with main and rerun bootstrap? Then I think this is good to go. Thanks for all the work on this.

[sayrer]

Merged main, running bootstrap had no effect vs the commit with the Tera fix.

[dfreese]

Released in v0.16.0

[PiotrSikora]

I'm not sure if this is intentional or not, but rules for crates with default = ["std"] no longer include:

crate_features = [
    "default",
    "std",
],

(e.g. third_party/cargo/remote/BUILD.blake2b_simd-0.5.11.bazel in this PR), which brakes crates that verify that they were built with "std" feature enabled (e.g. BurntSushi/aho-corasick).

[bsilver8192]

Regenerating the examples with this PR makes many of them fail to build because no crates have any features enabled. I'm looking at fixing it, FYI for anybody else encountering random build failures.