eminence / procfs

Rust library for reading the Linux procfs filesystem
Other
362 stars 106 forks source link

Bitflags v2 #259

Closed tatref closed 1 year ago

tatref commented 1 year ago

Update to bitflags v2, it's a big update

Changelog is not clean yet, so migration path is not complete See https://github.com/bitflags/bitflags/issues/310

At the moment, I only updated the version, and implemented derived Copy, Clone, Debug, Hash, Eq, PartialEq, PartialOrd, Ord From the mentioned PR, seems like we'll need to add some repr(transparent) if we want serde to work.

Maybe it's better to wait until the complete migration guide is finished

tatref commented 1 year ago

I rebased from master, it should be good to go

tatref commented 1 year ago

Sorry i'm not super versed about dependencies/features selection

I tried the two following snippets:

[features]
serde1 = ["serde", "bitflags/serde"]

[dependencies]
bitflags = { version = "2" }
[features]
serde1 = ["serde", "bitflags/serde"]

[dependencies]
bitflags = { version = "2", no-default-features = true }

In both cases, cargo tree gives:

procfs v0.15.1 (/home/tatref/dev/linux-mem/procfs/procfs)
├── bitflags v2.3.1
│   └── serde v1.0.163
...

If I use cargo tree --features serde1, I get an additional serde v1.0.163 as a direct dependency below procfs v0.15.1

Any idea?

eminence commented 1 year ago

Did you make the change in both procfs and procfs-core ?

When I make this change locally, here's what I see:

❯ cargo tree 
procfs v0.15.1 (/nas/achin/devel/procfs/procfs)
├── bitflags v2.2.1
❯ cargo tree --features=serde1
procfs v0.15.1 (/nas/achin/devel/procfs/procfs)
├── bitflags v2.2.1
│   └── serde v1.0.152
│       └── serde_derive v1.0.152 (proc-macro)
│           ├── proc-macro2 v1.0.51
│           │   └── unicode-ident v1.0.6
│           ├── quote v1.0.23
│           │   └── proc-macro2 v1.0.51 (*)
│           └── syn v1.0.107
│               ├── proc-macro2 v1.0.51 (*)
│               ├── quote v1.0.23 (*)
│               └── unicode-ident v1.0.6
tatref commented 1 year ago

Seems like this was fixed as part of #270