11

Github Stabilize -Zfeatures and -Zpackage-features. by ehuss · Pull Request #899...

 4 years ago
source link: https://github.com/rust-lang/cargo/pull/8997
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Member

alexcrichton left a comment

Awesome and thanks so much for this! I think the new features chapter is getting a much needed rewrite and I like how it all reads and the information covered there. I didn't see that it would clearly fill any missing gaps in the documentation, but another crate which could serve as an example usage of features is web-sys which controls compile-time with features. This is very similar and less-well-known than winapi, however.

One thing I'd like to see is defaulting to resolver = "2" for new manifests, but presumably that will need to wait until this stabilization hits stable at least? (otherwise cargo +nightly new'd projects aren't buildable on stable)

allowing extended capabilities for platforms that support the full standard

library. The [`memchr`] package defines a [`std` feature] that is [enabled by

default][memchr-default]. At the top of the library, it [conditionally enables

the `no_std` attribute][memchr-nostd]. Then, in various places in the code, it

alexcrichton 28 days ago

Member

Technically I would not recommend this design to others (a conditional #![no_std] attribute), because it's generally easier to develop libraries if they unconditionally define the attribute and conditionally import std based on features. Then if items from std are desired they are imported in the relevant locations with use std::... (etc)

```toml

[features]

default = ["bmp", "png", "ico", "webp"]

alexcrichton 28 days ago

Member

Should this perhaps omit bmp and png to show that feature are recursively enabled?

> **Note**: Sometimes feature unification may be a little too aggressive. See

> the `resolver = "2"` option [described below](#feature-resolver-version-2)

> for improved behavior.

alexcrichton 28 days ago

Member

I think it might be better to not mention this here since this will soon become the default for almost everyone?

>

> In this situation, features "foo" and "bar" are enabled on the given

> members only if the member defines that feature. It is an error if none of

> the selected packages defines a given feature.

alexcrichton 28 days ago

Member

I'm a bit on the fence about the inline notes here about resolver=1/2. I find them useful personally but as the ecosystem shifts more and more to =2 then these notes will largely become clutter. Perhaps this chapter could be written from the perspective of a year from now with notes about resolver=1 at the end?

ehuss 28 days ago

Author

Contributor

Sure! That's something I struggle with in the Rust reference, too, trying to describe multiple editions at the same time. I removed the notes, since they were essentially just duplicating the same information, and aren't that important. I think in the future when "2" is the default, it can be tweaked some more.

`std`. For example:

```rust

#![cfg_attr(not(feature = "std"), no_std)]

alexcrichton 28 days ago

Member

In the spirit of additiveness, I think it'd be better to show here the unconditional #![no_std] followed by a conditional use std::... perhaps?


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK