qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@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 16:07:34 GMT
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.


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


Mime
View raw message