Crates.io | zbus-lockstep-macros |
lib.rs | zbus-lockstep-macros |
version | |
source | src |
created_at | 2023-08-31 12:28:39.882354 |
updated_at | 2024-12-02 18:44:57.946361 |
description | Macros to keep types in lockstep with DBus XML definitions |
homepage | |
repository | https://github.com/luukvanderduim/zbus-lockstep |
max_upload_size | |
id | 959892 |
Cargo.toml error: | TOML parse error at line 24, column 1 | 24 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
zbus-lockstep-macros
extends zbus-lockstep
to match the signature of signal types <T as zvariant::Type>::signature()
with a corresponding signature from a DBus XML file more conveniently and succinctly.
In the context of IPC over DBus
, especially where there are multiple implementations of servers and/or clients communicating, it is necessary for each implementation to send what others expect and that expectations are in accordance with what is sent over the bus.
The XML
protocol-descriptions may act as a shared frame of reference or "single source of all truth" for all implementers.
Having a single point of reference helps all implementers meet expectations on protocol conformance.
Keeping the types you send over DBus
in lockstep with currently valid protocol-descriptions will reduce chances of miscommunication or failure to communicate.
Add zbus-lockstep-macros
to Cargo.toml
's dependencies:
[dependencies]
zbus-lockstep-macros = "0.5.0"
If the DBus
XML descriptions can be found in the crates root,
in either xml/
or XML/
, validating the type can be as easy as:
use zbus_lockstep_macros::validate;
use zvariant::Type;
#[validate]
#[derive(Type)]
struct BirthdayEvent {
name: String,
new_age: u8,
}
Note that the macro assumes that the member name is contained in the struct name. You can provide the member name if you have another naming-scheme in use.
Also, it may be necessary to disambiguate if multiple interfaces across the DBus
descriptions provide signals with the same name.
Any of the arguments are optional.
#[validate(xml: <xml_path>, interface: <interface_name>, member: <member_name>)]
See also the crates docs for more detailed descriptions of the arguments.
MIT