[rabbitmq-discuss] RabbitMQ C Client Intermediate Status Source Code

David Wragg david at rabbitmq.com
Thu Jun 24 14:25:49 BST 2010


Hi Frank,

Thanks for putting your code up.

Frank Gönninger <frank.goenninger at consequor.de> writes:
> [...]
>
> Now, codegen.py emits GNU C specific code - that leaves us with "a lot
> of work" to modify codegen.py to
>
> A. Either emit ANSI C code using pure functions and avoid C "macros", or
>
> B. Emit the same #ifdef'ed code structure that has been used manually
> to adapt all other source and header files.

I'd strongly suggest option A.

In fact, I'd suggest that approach throughout the codebase.  Preserving
the gccisms using ifdefs will just makes the code harder to maintain,
without providing any particular benefits (the gccisms in the rabbitmq-c
codebase are interesting experiments, but in the cold light of day seem
a bit gratuitous).

> Meanwhile, due to presssing project deadlines, we stopped working on
> his approach and have resorted to the MINGW alternative for coding our
> application. In latest two months time, however, we will be facing a
> situation where we need to deliver a Visual Studio 2010 project used
> by the client to build the code (then to be deployed on a Windows
> Server 2008-based machine).

I know the problem of balancing deadlines and ideal solutions well.

I propose we look at merging some of your changes back into the main
rabbitmq-c repo.  While this won't yet give a pure ANSI rabbitmq-c, it
will at least move us closer to that ideal, and form a basis for future
work towards that goal.  As mentioned above, I'd prefer to kill the
gccisms completely wherever possible.  That might be as simple as
deleting the code under "#ifdef __GNUC__".

To make it possible to pull your changes back into rabbitmq-c, we will
need you to sign a contributor agreement.  I'll send you the details
off-list.

David

-- 
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware


More information about the rabbitmq-discuss mailing list