This extends the functionality of SDBUSCPP_REGISTER_STRUCT macro.
It now provides functionality for serializing a user-defined struct as an a{sv} dictionary, and for deserializing an a{sv} dictionary into a user-defined struct. The former one is achieved by decorating the struct with sdbus::as_dictionary(struct), the latter one is an automatic behavior -- when sdbus-c++ is asked to deserialize into a struct but the data in the message is of type a{sv}, then the dict-to-struct deserialization is performed automatically.
There are some aspects of behavior in the serialization/deserialization functionality that can be customized by the client. Newly introduced SDBUSCPP_ENABLE_NESTED_STRUCT2DICT_SERIALIZATION and SDBUSCPP_ENABLE_RELAXED_DICT2STRUCT_DESERIALIZATION macros serve the purpose.
Until now, the solution to ensure that even large messages are fully sent out has been to flush the connection queues after each sending of a message, which is likely an unnecessary call (with unnecessary cost) in vast majority of cases, and which may block the connection from doing other work until the large message is fully sent out. This was a rather quick, hacky workaround.
Now, after the sending the message we check whether it has been sent out fully or not. If not (outbound queues are non-empty), then we send a wake-up signal to the connection event loop. The event loop thread then fetches new sd-bus timeouts and events and will see that there are pending outbound messages to process, and will process them together with any other prospective pending events, until there is nothing to process (i.e., the outbound message has been fully dispatched).
Having explicit conversion operator is a good practice according to the C++ core guidelines, as it makes the code safer and better follows the principle of least astonishment. Also, it is consistent with the standard library style, where wrappers like std::variant, std::any, std::optional... also do not provide an implicit conversion to the underlying type. Last but not least, it paves the way for the upcoming std::variant <-> sdbus::Variant implicit conversions without surprising behavior in some edge cases.
This introduces strong types for `std::string`-based D-Bus types. This facilitates safer, less error-prone and more expressive API.
What previously was `auto proxy = createProxy("org.sdbuscpp.concatenator", "/org/sdbuscpp/concatenator");` is now written like `auto proxy = createProxy(ServiceName{"org.sdbuscpp.concatenator"}, ObjectPath{"/org/sdbuscpp/concatenator"});`.
These types are:
* `ObjectPath` type for the object path (the type has been around already but now is also used consistently in sdbus-c++ API for object path strings),
* `InterfaceName` type for D-Bus interface names,
* `BusName` (and its aliases `ServiceName` and `ConnectionName`) type for bus/service/connection names,
* `MemberName` (and its aliases `MethodName`, `SignalName` and `PropertyName`) type for D-Bus method, signal and property names,
* `Signature` type for the D-Bus signature (the type has been around already but now is also used consistently in sdbus-c++ API for signature strings),
* `Error::Name` type for D-Bus error names.
This improves the D-Bus object API registration/unregistration by making it more flexible, more dynamic, closer to sd-bus API design but still on high abstraction level, and -- most importantly -- less error-prone since no `finishRegistration()` call is needed anymore.
The test now works with Clang, libc++ and -O2 optimization, since the underlying implementation has been completely re-designed and doesn't suffer from that problem anymore.
This also introduces `always_false` technique instead of `sizeof` trick for unsupported D-Bus type representation static assert. This one is more expressive and leads to more specific, more revealing compiler error messages.
* chore: don't use systemd headers with elogind
In file included from src/VTableUtils.c:27:
src/VTableUtils.h:30:10: fatal error: 'systemd/sd-bus.h' file not found
#include <systemd/sd-bus.h>
^~~~~~~~~~~~~~~~~~
* chore: add basu support
Similar to elogind but also supported on non-Linux.
* chore(tests): permit /var/lib/machine-id on non-systemd
https://github.com/elogind/elogind/commit/84fdc0fc61c1https://git.sr.ht/~emersion/basu/commit/8324e6729231
* chore(ci): add simple freebsd job
Mainly to cover libc++ and basu.
* chore(ci): explicitly pass CMAKE_INSTALL_PREFIX
Some sdbus-cpp tests require configuring system bus. However, Linux
testing relies on writing outside of prefix in order to affect current
system bus instance instead of launching a dedicated one.
* chore(tests): respect CMAKE_INSTALL_PREFIX for system bus config
DBus isn't part of base system on BSDs, so may not use /etc for configs.
Also, testing installation failed as non-root:
$ cmake -DBUILD_TESTS=1 -DCMAKE_INSTALL_PREFIX=/tmp/sdbus-cpp_prefix -DTESTS_INSTALL_PATH=/tmp/sdbus-cpp_prefix/tests
$ cmake --build .
$ cmake --install .
[...]
CMake Error at tests/cmake_install.cmake:105 (file):
file cannot create directory: /etc/dbus-1/system.d. Maybe need
administrative privileges.
* chore(tests): temporarily skip 1 test on FreeBSD to keep CI happy
* chore(ci): run tests in freebsd job
* feat: support serialization of array, span and unordered_map
* fix some spelling mistakes
* docs: update table of valid c++ types
---------
Co-authored-by: Marcel Hellwig <github@cookiesoft.de>
fix timeout handling
* Despite what is documented in sd_bus_get_timeout(3), the timeout
returned is actually an absolute time point of Linux's CLOCK_MONOTONIC
clock. Hence, we first have to subtract the current time from the
timeout in order to get a relative time that can be passed to poll.
* For async call timeouts to reliably work, we need a way to notify the
event loop of a connection that is currently blocked waiting in poll.
I.e. assume the event loop thread entered poll with a timeout set to
T1. Afterwards, the main thread starts an async call C with a timeout
T2 < T1. In order for C to be canceled after its timeout T1 has
elapsed, we have to be able to notify the event loop so that it can
update its poll data.
Co-authored-by: Urs Ritzmann <ursritzmann@protonmail.ch>
Co-authored-by: Lukasz Marcul <lukasz.marcul@onemeter.com>
Even though they have the same value, they are something fundamentally different.
Therefore it is extremely confusing if the constant INTERFACE_NAME is passed
where actually a well-known BUS_NAME (destination) should go.
