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:[email protected]]
Sent: Tuesday, February 21, 2012 10:23 AM
To: [email protected]; Ted Ross; [email protected]
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.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
