[sdbusplus] To generate a common header for public information of interfaces

[William Kennington]

We should have common headers for this because I'd like to see us have a
typesafe client interface that is autogenerated with the server interface.
I wrote the code a while back to implement a typesafe sdbusplus client
interface but never finished the generator code that automatically defines
the types and DBus strings.

On Thu, Feb 13, 2020 at 6:39 AM Lei YU <mine260309 at gmail.com> wrote:

> Currently, sdbus++ generates the server code separately, and in
> phosphor-dbus-interfaces, the separated headers are installed, and the
> separated cpp files are combined together, and compiled as a library.
> The public information of the interfaces (e.g, the interface strings,
> the enum strings) are either in the separated header or in the cpp
> files.
>
> The result is, when a phosphor service needs to use an interface, or
> an enum, it has to define the interface string or the enum string
> manually, and it happens everywhere.
>
> How about
> 1. Making sdbusplus to generate a "common" header for each interface
> including the public information;
> 2. Then phosphor-dbus-interfaces could generate a single header file
> that includes all the public information of the interfaces;
> 3. Then the phosphor service could include a single header file, and
> use the interface/enum strings it needs, without manually defining
> them?
>
> There is an initial concept implementation:
> *
> https://github.com/mine260309/sdbusplus/commit/78cb63fb7e1ceb62165c71e15779f23f7e9f166c
> *
> https://github.com/mine260309/phosphor-dbus-interfaces/commit/6079d25547f0143fc7562a1c7ee6beb888a66432
>
> With the above changes, a service could directly use the generated
> interface string, e.g.
> `sdbusplus::xyz::openbmc_project::Software::ApplyTime::interface`.
> In the future, the enum strings could be put there and thus we do not
> have to manually write the long full qualified string.
>
> Ideas and suggestions are welcome.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200213/b83bdbea/attachment-0001.htm>