Hi, Gergely:
Gergely Nagy wrote:
> Robert Edmonds <edmo...@debian.org> writes:
>
> > riemann-c-client
> > ----------------
> >
> > Rebuilt by hand successfully against protobuf-c 1.0.0~rc2-1 from
> > experimental.
> >
> > Has an unversioned build dependency on libprotobuf-c0-dev. This
> > needs to be updated to libprotobuf-c-dev eventually.
>
> I can switch that to libprotobuf-c-dev | libprotobuf-c0-dev in the next
> upload (I'd like to be able to compile the package on wheezy without
> changes, hence the alternative). Since I just released a new upstream
> version of the library, I'll be doing an upload at some point anyway,
> I'll try to make it so that binNMUs won't be required after.
OK, "Build-Depends: protobuf-c-compiler, libprotobuf-c-dev |
libprotobuf-c0-dev" will work fine to preserve the ability to build on
wheezy. Eventually (post-jessie) I'd like to get rid of the
"libprotobuf-c0-dev" package name entirely.
> > Has a build dependency on protobuf-c-compiler and runs protoc-c
> > during the build.
> >
> > No protoc-c generated symbols are exported by libriemann-client0.
> >
> > The libriemann-client-dev package exports the following header files
> > generated by protoc-c:
> >
> > /usr/include/riemann/proto/riemann.pb-c.h
> >
> > However, I have not found any packages in the Debian archive which
> > utilize this file.
>
> The various riemann-c-client headers in /usr/include/riemann include
> proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from
> syslog-ng-incubator) that uses the library, thus, the generated header
> too, transitively.
Ah, right. From a brief look at the source code for that module it
looks like it doesn't require a (bin-)NMU at all, if I'm understanding
the libriemann-client API correctly.
> > I would recommend that the upstream developers ship a .proto file
> > instead.
>
> I'd rather not ship a .proto file, if at all possible. I'll see if I can
> hide it completely.
This would eliminate the problem, too.
It looks like you typedef the structures generated by protoc-c and wrap
them in your own API, e.g. from <riemann/query.h>:
#include <riemann/proto/riemann.pb-c.h>
typedef Query riemann_query_t;
riemann_query_t *riemann_query_new (const char *string);
void riemann_query_free (riemann_query_t *query);
int riemann_query_set_string (riemann_query_t *query, const char *string);
("Query" is from "typedef struct _Query Query" in riemann.pb-c.h.)
If your API callers always use the *_new(), *_free(), etc. functions and
never try to dereference or calculate sizeof() on the wrapped struct's
it might be possible to remove the #include of the .pb-c.h file and
change your typedef to, e.g.:
typedef struct _Query riemann_query_t;
And then have "riemann_query_t" be an opaque type. Though this depends
on protoc-c continuing to generate structure tags with leading
underscores, which may not always be the case. (I've wanted to get rid
of the leading underscores for a while now.)
(Similiarly for the other riemann_*_t types that wrap protoc-c generated
structures.)
It might also be possible to wrap the structure types generated by
protoc-c in your own opaque structure type and expose that wrapper type
via your API. Something like:
typedef struct riemann_query riemann_query_t;
riemann_query_t *riemann_query_new (const char *string);
void riemann_query_free (riemann_query_t *query);
int riemann_query_set_string (riemann_query_t *query, const char *string);
(In <riemann/query.h>.)
#include "proto/riemann.pb-c.h"
struct riemann_query {
Query query;
};
/* rest of the implementation... */
(In lib/riemann/query.c.)
That's a bit uglier since you have to update accesses to go via the
wrapper but would provide the maximum amount of insulation between the
libriemann-client API and the underlying structures generated by the
protoc-c code generator.
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
