OpenMAMA/OpenMAMA

fquinner

@fquinner

https://ci.appveyor.com/project/fquinner/openmama-gnbjp/builds/26437188/job/k29ee0g8cl9rsnu6 if you can see that

Chris Morgan

@cjwmorgan-sol

Sorry about that looks like the tests can not find the dqstrategy plugin. The build generated the plugin with the md suffix. I'm not sure if that is what should happen. I'll look into it.

Chris Morgan

@cjwmorgan-sol

Looks like the plugin dll was installed under lib instead of bin, see
-- Installing: C:/projects/openmama-gnbjp/openmama-6.2.3.win.x64/bin/libmamaplugindqstrategymd.pdb
-- Installing: C:/projects/openmama-gnbjp/openmama-6.2.3.win.x64/lib/libmamaplugindqstrategymd.dll

I do not recall modifying anything in that cmakelist

Chris Morgan

@cjwmorgan-sol

The dqstrategy plugin is created as a module instead of a shared library so cmake seems to be putting the plugin into the lib <install>/lib folder instead of the <install>/bin. Also the ci-run.py only seems to add the install bin folder and the install/bin/dynamic folder (no longer produced). I find this odd as I do not know how the dqstrategy plugin was ever loaded before. Unless my changes have inadvertently change where the plugin was installed I do not see how the test ran before in appveyor. I could change the library to be labeled as a shared library like base bridge and qpid bridge however the cmake docs would seem to indicate that 'module' is supposed to be used for dynamic runtime modules (anything that is 'dlopened'). To me this seems odd as the 'module' is installed into lib not bin.

@fquinner any thoughts?

fquinner

@fquinner

This rings a bell check out https://github.com/OpenMAMA/OpenMAMA/blob/next/mama/c_cpp/src/c/entitlement/noop/CMakeLists.txt

And the MSVC specific install target paths

Weird that it only manifests itself after those changes though

fquinner

@fquinner

Installing DLL to lib was in older versions too but unit tests still didn't fail

Yeah old versions failed with that too

mama_loadPlugin(): Could not open plugin library [dqstrategy] [126]

Well the tests didn't fail, but they reported that error

I expect your test failures may be unrelated to that though

Yeah hang on this rings a different bell can you merge the latest release branch?

fquinner

@fquinner

I think qpid broke compatibility (again)

I reverted for the rc builds and think I forgot to merge back into next

Yeah that's my bet try that and push back in

Chris Morgan

@cjwmorgan-sol

Hey @fquinner sorry about the wait my git skills are still not that great. I updated #396 by synchronizing the pr branch with OpenMAMA 6.3.0 branch hopefully that's what will be ok for the PR. Let me know if I need to do something else for the PR.

fquinner

@fquinner

OK awesome cheers will keep an eye out!

Windows looks better now anyway!

fquinner

@fquinner

That's it merged now thanks!

Chris Morgan

@cjwmorgan-sol

Hey @fquinner I'm trying to address the issue described in #297 in the bridge I'm working on and I found that the openmama Payload tests for update sub msg segfault as they still pass a msgPayload not a mamaMsg. I really think the bridge function definition should be updated and the co-responding tests should be updated before 6.3.0 is made to officially release. What you think?

Chris Morgan

@cjwmorgan-sol

Also I checked out the OpenMAMA docker image looks like the "latest" tag points to 6.2.2? Will there be a 6.3.0 docker image? Also will there be docker images for release candidates? (I am interested in how and what to expect for docker image release for openmama.)

fquinner

@fquinner

Yeah I'm OK for changing to be honest I don't think many people make use of submsg anyway, and updating to support would be an easy fix

Yeah latest is a copy of whatever was in next at the time I was testing I'll do new release once 6.3.0 is released

Chris Morgan

@cjwmorgan-sol

@fquinner when do think you get commit the bridge interface updates?

fquinner

@fquinner

I thought you were working on those?

Or do you mean something unrelated to #297?

Chris Morgan

@cjwmorgan-sol

Nope, I can update the bridge interface if you need me to. I only got a build environment for c and cpp but I think the bridge interface is only accessed through c so all the other bindings would be fine, correct?

Chris Morgan

@cjwmorgan-sol

Also @fquinner do you think that making the bridge interface consistent would be a good idea? For example mamaMsg_updateSubMsg should now pass a mamaMsg to the payload when the mamaMsg_addMsg passes a msgPayload? Should updated as well to make the api consistent?

fquinner

@fquinner

yes for the bridge, C is all you need to worry about

and yes I think mamaMsg is better leaves opportunity open for transcoding

(and thanks :))

Chris Morgan

@cjwmorgan-sol

Hey @fquinner do you think mamaMsg_applyMsg is also a candidate for transcoding message from the payload bridge?

Chris Morgan

@cjwmorgan-sol

Created pull request #397. It does not include changes for mamaMsg_applyMsg @fquinner if you think its worth it to make similar changes let me know.

fquinner

@fquinner

It probably is worth it yeah but would need to run that one by the mailing list I know its much more commonly used so community may be more opposed to breaking changes in that area

Chris Morgan

@cjwmorgan-sol

Hmm looks like some tests that were disabled (which I accidently enabled) failed. Interestingly enough they passed when I ran them. I guess the qpid bridge has some issue with those tests?

Nope my testing scripts try to skip certain tests that's probably why

Chris Morgan

@cjwmorgan-sol

Looks like the only test failures are the ones a accidentally enabled. I'll disable them again to hopefully get a clean merge.

fquinner

@fquinner

Awesome sounds good thanks!

Chris Morgan

@cjwmorgan-sol

Looks like I got a clean build for #397.

fquinner

@fquinner

Yeah I saw that thanks will get a proper review shortly, need to send note out to mailing list too

Chris Morgan

@cjwmorgan-sol

Hey @fquinner I'm having some trouble building my bridges on windows without scons. I've changed how my bridges build to no longer use scons. However my bridge depends on the port.h header which seems to include a <windows/lock.h> which is not a part of the install directory from build openmama with cmake. Should the port.h on windows be including the <windows/lock.h>?

Chris Morgan

@cjwmorgan-sol

I noticed that the sample qpid bridge includes internal wombat common source directories in it's cmake lists. Are bridges required to have the openmama source in order to build? I was under the impression that bridges no longer needed openmama source to build.

fquinner

@fquinner

Bridges definitely shouldn't need openmama source to build that's what the integration headers are supposed to be for (if required)

It sounds like the path of least resistance is simply to include those files on windows cmake install

Qpid does it because mama it may not be building against an "installed" openmama codebase so it has to use code relative the source tree

fquinner

@fquinner

If it was an external bridge it wouldn't do that

Chris Morgan

@cjwmorgan-sol

Ok sounds reasonable to me, thanks. After #397 gets merged and a fix for #398 is done do you think it would be a good point to get a 6.3.0-rc2?

fquinner

@fquinner

Yeah I have been on holidays most of August (and still am) hence the tardiness :)

Where communities thrive

People

Repo info

Activity