Try to reduce the dependency graph

[elinorbgr]

the dependency graph of wayland-rs is relatively large, which seems a little big for a low-level crate like this. We probably can try to reduce it.

[kchibisov]

You don't need regex for xcursor-rs crate at all, so it could be all wiped if you're fine taking similar impl from someone under wayland-rs upstream. if you're fine I can send patches.

[jplatte]

If regex is removed, it should be easy to get rid of lazy_static too, by replacing it with once_cell which wayland-commons already depends on.

[kchibisov]

Basically one can be replaced with another, right, since after regex removal both should be just leafs on this graph afaics, so it's a matter of preference, what suits more, I guess?

[kchibisov]

regex was removed.

[elinorbgr]

Yes, now the graph looks like that:

One I'd like to figure out how to remove would be parking_lot, which currently provides a ReentrantMutex that wayland-server uses to ensure that the ffi to libwayland-server.so is never accessed from two different threads conccurently, as the lib as a whole is basically !Sync.

[kchibisov]

Why winapi is on that graph?

[elinorbgr]

Mostly because cargo deps is not very good at filtering platform-specific dependencies, I think.

[kchibisov]

well, we see that nom is a big problem here, maybe one could rewrite xcursor parsing without it :- )

[jplatte]

well, we see that nom is a big problem here, maybe one could rewrite xcursor parsing without it :- )

What about this instead? esposm03/xcursor-rs#6 :)

[kchibisov]

How much it reduces @jplatte ?

[jplatte]

That removes the dependency on lexical-core, which means the dependencies on cfg-if, ryu, static-assertions, arrayvec and rustc_version also disappear as xcursor deps (though wayland-rs will continue to depend on cfg-if).

[kchibisov]

The mentioned PR was merged and xcursor version was bumped, so graph could be updated.

[jplatte]

By playing with the command line flags until I had this: cargo deps --no-transitive-deps --subgraph wayland-test wayland-protocols wayland-egl wayland-server wayland-client wayland-cursor wayland-scanner wayland-commons wayland-sys --subgraph-name wayland-rs | dot -Tpng > graph.png

I got the following updated graph:

[jplatte]

By excluding wayland-scanner and its dependencies (I'm guessing it's not flagged as a build dependency because it's part of the workspace) and target-specific features for platforms that wayland doesn't run on (winapi, cloudabi, redox_syscall, wasi), the remaining dependencies that actually contribute to the output size are:

Of which I think

• lazy_static can trivially be replaced by once_cell, then later by std potentially (see standard lazy types rust-lang/rfcs#2788)
• byteorder might be replaceable with the corresponding functionality in std (see Tracking issue for integer types conversion to and from byte arrays rust-lang/rust#52963, stabilized in 1.32.0)

Can't say much about the other ones, but I think there won't be much more to get rid of :)

[kchibisov]

tempfile shouldn't be on a graph as well, I guess, since it was excluded manually from previous graphs, since it's a build time dependency.

[jplatte]

[elinorbgr]

tempfile and byteorder are actual dev-dependencies of wayland-client, and are only used in the examples, so these can be excluded. cargo deps does not yet handle correctly dev-deps in workspaces.

[jplatte]

Oh, okay, that's what going wrong :)

So all that's left to do it potentially find a replacement for parking_lot, and replacing lazy_static with once_cell? Sounds like this issue could be closed in favor of two new issues that track those specific todos, right?

[elinorbgr]

Well, parking-lot will be difficult to get rid of by itself, but will probably disappear when I implement the ideas from #317. I'm not sure if there is much to gain by getting rid of lazy_static, as it is a quite pervasive crate, hence there is a high probability that it already appears somewhere else in the dependency graph anyway. So I think we can call it a day for now.