[jira] Commented: (QPID-1780) Remove boost dependencies from C++ client API

2009-03-30 Thread James Mansion (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12693993#action_12693993
 ] 

James Mansion commented on QPID-1780:
-

I'm not sure the position is any better on RHEL or other *nix systems - the 
system-supplied Boost package evolves slowly and I'm likely to want a more 
modern one.

All platforms will often have the client built from source in a customer C++ 
application, I suspect, and packagers will choose a common Boost library for 
distributions.

If there is going to be a lightweight C API with a supported swig/sip/whatever 
interface, why worry?  Shouldn't that be the supported binary client?



 Remove boost dependencies from C++ client API
 -

 Key: QPID-1780
 URL: https://issues.apache.org/jira/browse/QPID-1780
 Project: Qpid
  Issue Type: Bug
  Components: C++ Client
Affects Versions: M4
Reporter: Steve Huston

 Currently there is a dependency on Boost headers being present when building 
 a Qpid client application. I believe that Qpid client programmers should not 
 have to be exposed to Boost just for building Qpid applications. It's a Bad 
 Idea to impose a requirement such as this on all users - Boost is a 
 supporting artifact of the implementation and shouldn't be a requirement for 
 users.
 More pointedly, it could cause version skew on Windows installed kits. Unlike 
 on RHEL, Windows doesn't offer Boost packages as part of the vendor-supplied 
 OS kit. So, Windows users needing Boost must get their kit somewhere else. 
 This makes it impossible to predict what version of Boost will (or won't) be 
 on a user's system. To take care of this, the Windows installable kit is 
 currently including the needed Boost DLLs that the kit is built against 
 within the install. This removes the need to have Boost installed by the user 
 prior to installing/using Qpid and isolates Qpid's binaries from whatever 
 Boost version is present if there is one. This is a Good Thing except that 
 when trying to build a client app (such as the Qpid examples) Boost ends up 
 getting pulled in from the client API at build time. This is bad because the 
 user now needs to go install Boost. If it's not the same version that the 
 installed kit was built against, there's a chance that object sizes, methods, 
 etc. will differ between what Qpid was built with and what the user installed.
 The case that brought this up immediately is that qpid/SessionId.h derives 
 from boost::totally_ordered1SessionId. Since 
 qpid/client/Session_Base_0_10.h defines a method which returns a SessionId by 
 value, it needs to pull in SessionId.h which yields a compile error if Boost 
 is not available.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Created: (QPID-1737) qpid C++ will not build with WinSDK 7

2009-03-13 Thread James Mansion (JIRA)
qpid C++ will not build with WinSDK 7
-

 Key: QPID-1737
 URL: https://issues.apache.org/jira/browse/QPID-1737
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: M4
 Environment: XP 32 bit with latest SDK from Microsoft (SDK 7 beta)
Reporter: James Mansion


I'm trying to build M4 of AMQP on XP with the Win7 SDK Beta, and I'm seeing that

Manageable::STATUS_INVALID_PARAMETER

is being expanded to:

Manageable::((DWORD )0xC00DL);

I think this is because src\qpid/sys/windows/uuid.h has included rpc.h and 
included a lot of the SDK as a result.

STATUS_INVALID_PARAMETER is defined in ntstatus.h and winnt.h.

The include structure is rather Byzantine - I see there's a JIRA to tidy things 
up, though that is focussed on client applications.

I suspect that one way or another this will bite again even if sufficient 
'undefs' are added in the code now.

I know this is Microsoft's bad for namespace pollution, but the practical 
answer is to change the name of this constant. 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Updated: (QPID-1737) qpid C++ will not build with WinSDK 7

2009-03-13 Thread James Mansion (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPID-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Mansion updated QPID-1737:


Attachment: SIP.patch

Patch attached - replaces STATUS_INVALID_PARAMETER with 
STATUS_PARAMETER_INVALID.

 qpid C++ will not build with WinSDK 7
 -

 Key: QPID-1737
 URL: https://issues.apache.org/jira/browse/QPID-1737
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: M4
 Environment: XP 32 bit with latest SDK from Microsoft (SDK 7 beta)
Reporter: James Mansion
 Attachments: SIP.patch


 I'm trying to build M4 of AMQP on XP with the Win7 SDK Beta, and I'm seeing 
 that
 Manageable::STATUS_INVALID_PARAMETER
 is being expanded to:
 Manageable::((DWORD )0xC00DL);
 I think this is because src\qpid/sys/windows/uuid.h has included rpc.h and 
 included a lot of the SDK as a result.
 STATUS_INVALID_PARAMETER is defined in ntstatus.h and winnt.h.
 The include structure is rather Byzantine - I see there's a JIRA to tidy 
 things up, though that is focussed on client applications.
 I suspect that one way or another this will bite again even if sufficient 
 'undefs' are added in the code now.
 I know this is Microsoft's bad for namespace pollution, but the practical 
 answer is to change the name of this constant. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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