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. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
