qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: svn commit: r1291436 - in /qpid/trunk/qpid/cpp: include/qpid/framing/ include/qpid/types/ managementgen/qmfgen/ managementgen/qmfgen/templates/ src/qmf/ src/qpid/broker/ src/qpid/ha/
Date Tue, 21 Feb 2012 20:12:05 GMT
On Tue, 2012-02-21 at 11:07 -0500, Ted Ross wrote:
> On 02/21/2012 11:05 AM, Alan Conway wrote:
> > On Tue, 2012-02-21 at 09:29 -0600, Steve Huston wrote:
> >>> -----Original Message-----
> >>> From: Alan Conway [mailto:aconway@redhat.com]
> >>> Sent: Tuesday, February 21, 2012 10:23 AM
> >>> To: dev@qpid.apache.org; Ted Ross; astitcher@redhat.com
> >>> Subject: Re: svn commit: r1291436 - in /qpid/trunk/qpid/cpp:
> >>> include/qpid/framing/ include/qpid/types/ managementgen/qmfgen/
> >>> managementgen/qmfgen/templates/ src/qmf/ src/qpid/broker/
> >>> src/qpid/ha/
> >>>
> >>> On Mon, 2012-02-20 at 18:21 -0500, Andrew Stitcher wrote:
> >>>> On Mon, 2012-02-20 at 17:28 -0500, Alan Conway wrote:
> >>>>> ...
> >>>>> That is because there was no code outside of libqpidbroker calling
> >>>>> the generated functions (except for cluster.so but that is never
> >>>>> built on
> >>>>> windows.) The ha plugin now also calls some QMF generated functions.
> >>>>>
> >>>>> Perhaps a better solution is to move the QMF generated code for
each
> >>>>> plugin into the plugin library itself, rather than putting it all
> >>>>> into libqpidbroker. If that's preferable I can do that.
> >>>>>
> >>>> I'd say that would be the most preferable idea - any generated code
> >>>> should only be included with the code that actually uses it. This is
> >>>> particular irritation with the current cluster implementation IMO.
> >>> So if we move the cluster&  ha generated QMF code into their respective
> >>> plugins, do we then want to remove all the EXTERNs in the remaining broker
> >>> QMF code or leave it there for possible future use?
> >> Does the generated code to be in the plugins call the remaining broker QMF
> >> code?
> > Good point, I had overlooked that. The ha plugin does use the
> > definitions for broker events such as queue-create etc. So we would
> > still need EXTERNS in the qmf code even if we move the plugin-specific
> > qmf code into the plugin directories.
> >
> >
> Another possibility is to have the code generator create the proper raw 
> externs for the environment (gcc, MS, mingw32) rather than use the macros.

I'd prefer to use the macros. We can't use the raw externs in
non-generated code, and I think it's best to be consistent between
generated and non-generated code.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message