Open luukvanderduim opened 6 months ago
Yes... I think you're right about that.
No, I don't think you can disable a festure when another is enabled.
I think this was changed when async-std and tokio were both allowed as features of zbus. And I said "oh good! now I don't have to worry about atspi having both either!"
But I think you're right to be concrrned here.
I have consulted the zbus
sources:
This seems to affect error_message
only - I think?
#[cfg(all(not(feature = "async-io"), not(feature = "tokio")))]
mod error_message {
#[cfg(windows)]
compile_error!("Either \"async-io\" (default) or \"tokio\" must be enabled. On Windows \"async-io\" is (currently) required for UNIX socket support");
#[cfg(not(windows))]
compile_error!("Either \"async-io\" (default) or \"tokio\" must be enabled.");
}
I did find instances like:
/// Runs a single task.
///
/// With `tokio` feature enabled, its a noop and never returns.
pub async fn tick(&self) {
#[cfg(not(feature = "tokio"))]
{
self.executor.tick().await
}
#[cfg(feature = "tokio")]
{
pending().await
}
}
At first glance I'd say it is unreasonable to allow both enabled. I will try to enable both in a test program and break something and make lots of drama elsewhere ;')
In
atspi/src/lib.rs
https://github.com/odilia-app/atspi/blob/c3338f4373ca5c0240e7dc9d3fddf832e102ecaf/atspi/src/lib.rs#L10C1-L11C89This warns us when neither "async-std" or "tokio" is set.
What about having both set? This could easily happen I were to
I believe this leads to having the default feature "async-std" set as well as "tokio". Right? Is there a way to unset one if the other is set automatically and vice versa?