feat: allow for disabling crossbeam-channel #33
Conversation
|
I can't believe it's that simple! Do you have any resources on this funky behavior? EDIT: Sorry! I saw the link in your comment. |
|
wow |
|
So, I will merge and create a new minor version tomorrow, when I have some time to look into this closely. |
Thx a lot for your time! |
| recovery = ["sysinfo"] | ||
| log-trace = [] # test only | ||
| log-debug = [] # test only | ||
| crossbeam-channel = ["notify/default"] | ||
| no-crossbeam-channel = ["notify/macos_kqueue"] |
There was a problem hiding this comment.
So, what has made me a bit uneasy was this: every time we compile for a MacOS target we would have to use this no-crossbeam-feature? Could we use [target.'cfg(target_os = "macos")'.dependencies] instead? (I have googled and it says this is a bit broken, but at least worth a shot. Else, could we use. cfg in the code directly?)
There was a problem hiding this comment.
I thought about that at first, and it did work as well, but I believe it is actually related to using the tokio runtime rather than macOS. I did not test this under Linux though to confirm if this really the case.
The reason why it is needed to require kqueue is because notify does not provide a default for macOS if you don't use the default feature.
As it turns out,
tokiodoes not mix well withnotifywhencrossbeam-channelsare enabled (see here).In my tests with
yaqueadded this way to my deps, it seems to work as expected (with this PR in place):Fixes #32