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 Mon, 20 Feb 2012 22:28:34 GMT
On Mon, 2012-02-20 at 16:23 -0500, Ted Ross wrote:
> The scope of this fix seems to be much greater than that of the commit 
> that broke Windows.

It looks that way because in the original commit you only see the new
code for the HA plugin being added. You don't see the set of functions
in libqpidbroker that are being called by that new code - which is what
you see in the fix commit.

> A couple of questions:
> 1) Why add "BrokerImportExport.h" to cpp/src/qmf?  There's already a 
> cpp/include/qmf/ImportExport.h that serves the same purpose.

It doesn't. qmf/ImportExport.h defines EXTERNS for the qmf.so library.
The generated code doesn't go in that library, it goes in
libqpidbroker.so. Hence the awkward BrokerImportExport for the generated

> 2) Why all the changes to the generated code?  The old generation 
> templates worked fine under Windows.

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.

> The main thing you need to be concerned with is that any classes and 
> class methods that need to be accessible from outside the 
> DLL/shared-object are prefixed with the proper EXTERN symbol *for the 
> library*.  Furthermore, there's a different EXTERN symbol for inline 
> methods.

Correct, and as things are currently linked the ha plugin needs to call
QMF generated symbols in libqpidbroker so they need EXTERNs. Why do we
need EXTERNs for inline code? From what I saw making the changes, we
don't currently have EXTERNS on many/most inline functions in

I'll be happy to fix this up however we decide is best.


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

View raw message