Date   

Code change(s) just landed on origin/next (Still Failing)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] UT: Fixed unit test for modifyable payloads (#241)
	mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #113
  • Build Status: Still Failing
  • Build Warnings:
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Fixed)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] UT: Fixed unit test for modifyable payloads (#241)
	mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #119
  • Build Status: Fixed
  • Build Warnings: 2
  • Total Amount of Tests: 1769
  • Passed: 1769
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Fixed)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] UT: Fixed unit test for modifyable payloads (#241)
	mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #119
  • Build Status: Fixed
  • Build Warnings: 2
  • Total Amount of Tests: 1769
  • Passed: 1769
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Failure)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] COMMON: Added new method for finding a file in a PATH (#240)
	common/c_cpp/src/c/wombat/environment.h
	common/c_cpp/src/gunittest/c/UnitTestCommonC.vcxproj
	common/c_cpp/src/c/fileutils.c
	common/c_cpp/src/c/wombat/fileutils.h
	common/c_cpp/src/gunittest/c/utiltest.cpp
	common/c_cpp/src/c/commonc.vcxproj
	mama/c_cpp/src/gunittest/c/dictionarytest.cpp
	common/c_cpp/src/gunittest/c/SConscript
	common/c_cpp/src/c/SConscript.win


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #112
  • Build Status: Failure
  • Build Warnings:
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Failure)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] COMMON: Added new method for finding a file in a PATH (#240)
	common/c_cpp/src/c/wombat/environment.h
	common/c_cpp/src/gunittest/c/UnitTestCommonC.vcxproj
	common/c_cpp/src/c/fileutils.c
	common/c_cpp/src/c/wombat/fileutils.h
	common/c_cpp/src/gunittest/c/utiltest.cpp
	common/c_cpp/src/c/commonc.vcxproj
	mama/c_cpp/src/gunittest/c/dictionarytest.cpp
	common/c_cpp/src/gunittest/c/SConscript
	common/c_cpp/src/c/SConscript.win


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #112
  • Build Status: Failure
  • Build Warnings:
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Unstable)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] COMMON: Added new method for finding a file in a PATH (#240)
	mama/c_cpp/src/gunittest/c/dictionarytest.cpp
	common/c_cpp/src/c/SConscript.win
	common/c_cpp/src/c/commonc.vcxproj
	common/c_cpp/src/c/wombat/environment.h
	common/c_cpp/src/c/fileutils.c
	common/c_cpp/src/gunittest/c/UnitTestCommonC.vcxproj
	common/c_cpp/src/gunittest/c/utiltest.cpp
	common/c_cpp/src/c/wombat/fileutils.h
	common/c_cpp/src/gunittest/c/SConscript


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #118
  • Build Status: Still Unstable
  • Build Warnings: 2
  • Total Amount of Tests: 1769
  • Passed: 1768
  • Failed: 1
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Unstable)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] COMMON: Added new method for finding a file in a PATH (#240)
	mama/c_cpp/src/gunittest/c/dictionarytest.cpp
	common/c_cpp/src/c/SConscript.win
	common/c_cpp/src/c/commonc.vcxproj
	common/c_cpp/src/c/wombat/environment.h
	common/c_cpp/src/c/fileutils.c
	common/c_cpp/src/gunittest/c/UnitTestCommonC.vcxproj
	common/c_cpp/src/gunittest/c/utiltest.cpp
	common/c_cpp/src/c/wombat/fileutils.h
	common/c_cpp/src/gunittest/c/SConscript


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #118
  • Build Status: Still Unstable
  • Build Warnings: 2
  • Total Amount of Tests: 1769
  • Passed: 1768
  • Failed: 1
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[Frank Quinn] Added some fixes for Visual Studio on Windows
	OpenMama.sln
	msvc/PropertySheetProtonWin64Release.props
	mama/c_cpp/src/testtools/capturereplay/c/captureconvert.vcxproj
	mama/c_cpp/src/c/generateMamaSourceFiles.bat
	mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp
	msvc/PropertySheetProtonWin32Release.props


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #111
  • Build Status: Successful
  • Build Warnings: 158
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Unstable)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[Frank Quinn] Added some fixes for Visual Studio on Windows
	OpenMama.sln
	mama/c_cpp/src/testtools/capturereplay/c/captureconvert.vcxproj
	msvc/PropertySheetProtonWin32Release.props
	msvc/PropertySheetProtonWin64Release.props
	mama/c_cpp/src/c/generateMamaSourceFiles.bat
	mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #117
  • Build Status: Still Unstable
  • Build Warnings: 2
  • Total Amount of Tests: 1767
  • Passed: 1765
  • Failed: 2
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Unstable)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[Frank Quinn] Added some fixes for Visual Studio on Windows
	OpenMama.sln
	mama/c_cpp/src/testtools/capturereplay/c/captureconvert.vcxproj
	msvc/PropertySheetProtonWin32Release.props
	msvc/PropertySheetProtonWin64Release.props
	mama/c_cpp/src/c/generateMamaSourceFiles.bat
	mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #117
  • Build Status: Still Unstable
  • Build Warnings: 2
  • Total Amount of Tests: 1767
  • Passed: 1765
  • Failed: 2
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] PLAT-839: Default value of mama.msg.allowmodify changed from "false" to
	mama/c_cpp/src/c/mama.c


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #110
  • Build Status: Successful
  • Build Warnings: 158
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Fixed valgrind reported issues with unit tests (#236)
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp
	mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #109
  • Build Status: Successful
  • Build Warnings: 158
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Unstable)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] PLAT-839: Default value of mama.msg.allowmodify changed from "false" to
	mama/c_cpp/src/c/mama.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #116
  • Build Status: Still Unstable
  • Build Warnings: 2
  • Total Amount of Tests: 1767
  • Passed: 1765
  • Failed: 2
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Unstable)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] PLAT-839: Default value of mama.msg.allowmodify changed from "false" to
	mama/c_cpp/src/c/mama.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #116
  • Build Status: Still Unstable
  • Build Warnings: 2
  • Total Amount of Tests: 1767
  • Passed: 1765
  • Failed: 2
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Unstable)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Fixed valgrind reported issues with unit tests (#236)
	mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #115
  • Build Status: Still Unstable
  • Build Warnings: 2
  • Total Amount of Tests: 1767
  • Passed: 1766
  • Failed: 1
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Still Unstable)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[noreply] Fixed valgrind reported issues with unit tests (#236)
	mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp
	mama/c_cpp/src/gunittest/c/payload/payloadgeneraltests.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #115
  • Build Status: Still Unstable
  • Build Warnings: 2
  • Total Amount of Tests: 1767
  • Passed: 1766
  • Failed: 1
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


FW: Should we make the jump to cmake?

Keith Rudd
 

 

 

From: Keith Rudd
Sent: 26 October 2016 15:52
To: 'Glenn McClements' <gmcclements@...>
Subject: RE: Should we make the jump to cmake?

 

A bit late on this trail, but my input is that cmake would be a good choice for us.

We use cmake for building our internally packaged product that includes OpenMAMA, so it would make integration that bit easier for us.

 

Regards,

Keith

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Glenn McClements
Sent: 17 October 2016 16:14
To: openmama-dev@...
Cc: Frank Quinn <fquinn@...>
Subject: [Openmama-dev] Should we make the jump to cmake?

 

Sending on behalf of Frank (mail issues):

 

 

Hi Folks,

 

I have been giving quite a bit of consideration recently to making life easier for setting up new development environments for 3 developer types across all languages (particularly targeting windows as a development platform):

 

·         Users of OpenMAMA

·         Developers of OpenMAMA bridges

·         OpenMAMA contributors

 

I found myself getting repeatedly frustrated with the build system. It’s inflexibility makes many things awkward, and I found my options limited because of having to support all of the build systems we have available (particularly handling build directory structures of third party libraries on windows). Today we have scons for linux, scons for windows (yes – they are fairly separate for some reason), and Visual Studio project files for Windows IDE developers so any time you make a change, you really need to consider all 3.

 

Today in our build infrastructure, we use Scons which is grand, but we already have a lot of things that you have to hack together for scons, but which you actually get out of the box with Cmake like toolchain discovery.

 

I have started playing with it on a small scale and I think it is a really good fit for OpenMAMA because it:

 

·         Generates project files for you so you don’t need to check them into source control – they’ll all get generated from the same definition files

·         They have some library discovery mechanisms built in

·         They have install rules that make sense on both linux and windows

·         It can be used to generate .msi installer executables in conjunction with Wix (!)

·         Allows easy integration with external project types (I’m thinking specifically for C# for this one – mono and visual studio both use msbuild)

·         Takes care of DESTDIR and SONAME functionality which has been requested by package-creators in the past (i.e. for rpm / dpkg)

·         Single build system would simplify CI by not requiring changes in both scons and visual studio on windows

·         It has native IDE integration with many platforms and looks like it might even be on its way for Visual Studio

 

Interestingly, both libevent and qpid proton use cmake, as does almost every other cross-platform C/C++ project that I have stumbled across in the last number of months. With that in mind, I propose that we move our build system to Cmake and end this fun of having to update 3 different built system files every time a new source code file is added.

 

Any opinions either pro or against are welcome. Also if anyone is key to pitch in with the implementation, please chime in!

 

Cheers,

Frank

 

 

 

GLENN MCCLEMENTS

SVP Engineering, Europe

gmcclements@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Re: Should we make the jump to cmake?

Frank Quinn <fquinn@...>
 

Yeah that ticket exists mainly to see if we can avoid multiple build targets – we already have a rat’s nest of build targets on windows between architecture, debug, optimized and debug so I’m reluctant to add more if it’s avoidable.

 

It doesn’t include avis any more (avis isn’t even in core any more) but it does include qpid as the reference implementation as I expect most people who compile OpenMAMA will want a middleware too (bridge developers would be the exception here rather than the rule). It should compile fine without it though you can just disable that project in the solution and remove it as a dependency for MAMA and you’re done.

 

With new build instructions though you should be up and running in no time with Qpid (that’s why I put them together). It’s not like it was before with magic hacking of third party source to get it to build – this just works with copy and paste commands from instructions to install and once it’s installed, it is installed to a standard path which our build systems now default to so you don’t have to mess about with PROTON_HOME, EVENT_HOME etc any more either.

 

Cheers,

Frank

 

From: Tom Doust [mailto:tom.doust@...]
Sent: 24 October 2016 09:48
To: Frank Quinn <fquinn@...>; openmama-dev <openmama-dev@...>
Subject: RE: [Openmama-dev] Should we make the jump to cmake?

 

I was wondering if we need to think about multiple build targets – user dev, mama runtime, bridge dev etc.

 

Or is that more complicated than necessary.

 

Also, (and I may just be out of date here because I always just build a minimal subset of OpenMAMA for my dev environment) does the OpenMAMA build still include avis and qpid bridges – if it does, it shouldn’t because I don’t want to have to install 3rd party sdks to be able to do the build.

 

It may be worth thinking about how to structure bridge builds so they can sit along site OpenMAMA and get optionally included in builds if people want them. We would be happy to change our open source bridges to conform to this.

 

Tom

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 24 October 2016 09:39
To: Tom Doust <
tom.doust@...>; openmama-dev <openmama-dev@...>
Subject: RE: [Openmama-dev] Should we make the jump to cmake?

 

Yeah you’ve touched on what I said on the other thread there – the libs are actually fine as-is but the headers are definitely missing which are required for bridge development. Honestly I’ve been meaning to go through these header files with a fine toothed comb and see if:

 

A.      These functions are safe enough to just open up in the public headers

B.      The functions are too dangerous to open up

 

If A turns out to be the case, I’m tempted to just make the functions public and be done with it

If B turns out to be the case, I’m still inclined to put the functions in a public header but possibly have an #ifdef BRIDGE inside so they’ll only be available by default to bridge developers.

 

As I recall there are only actually a couple of methods that are required by the bridge that are not public by default so making your life easier might not be as tricky as it sounds. I just raised https://github.com/OpenMAMA/OpenMAMA/issues/234 to track this effort.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Tom Doust
Sent: 24 October 2016 09:26
To: Damian Maguire <
dmaguire@...>; Glenn McClements <gmcclements@...>; Dmitri Fedorov <Dmitri.Fedorov@...>; Alpert, Reed <reed.alpert@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

As Reed mentioned we currently use CMake. I think the OpenMAMA devs were considering going there at one point but mysteriously lurched in the direction of Scons within days of Tick42 deciding to use CMake J

 

I am very happy to stick with CMake. I just about understand it and our devs seem to be happy with it.

 

While we are talking about builds, from a bridge development perspective, the output from the current open mama build (headers and libs sdk) is not usable for bridge development. You need some of the headers that are embedded in amongst the C source files (rather than in the various include directories). Its not such a big deal for internal development but when you are contributing bridge code into open source it makes documenting the build process more work.

 

On windows my preference is for one or more sln files and just firing up Visual Studio and hitting “Rebuild All” My experience with msbuild and scripting it is mostly negative both from the point of view of developing scripts and using them. It’s not as good as nmake J

 

Tom

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Damian Maguire
Sent: 18 October 2016 16:28
To: Glenn McClements <
gmcclements@...>; Dmitri Fedorov <Dmitri.Fedorov@...>; Alpert, Reed <reed.alpert@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

- Somehow I managed to drop the mailing list responding to this earlier. Sorry about that. 

 

In an effort to avoid bike-shedding this one, I'll say nothing more than I think using CMake is a great idea. 

 

(Side Note: Reed, you're correct that OpenMAMA currently supports OSX as well. CMake integration should make this simpler as well, eliminating the need for the 'Darwin' specific Scons files.)

 

Cheers, 

 

D

 

DAMIAN MAGUIRE 

Senior Sales Engineer 

 

O. +44 289 568 0298  

M. +44 783 584 4770 

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD  

velatradingtech.com | @vela_tt

 

1467620971571_PastedImage


From: openmama-dev-bounces@... <openmama-dev-bounces@...> on behalf of Alpert, Reed via Openmama-dev <openmama-dev@...>
Sent: 17 October 2016 22:44:47
To: Glenn McClements; Dmitri Fedorov
Cc:
openmama-dev@...
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

Hi,

 

CMake is fine for us, Tick42 uses it now so we have it integrated into our build systems.

Most important is making it easy to change a build feature and do it on one place.

 

Are there other O/S for OpenMAMA – Apple?

 

Thanks,

 

Reed.

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Monday, October 17, 2016 12:00 PM
To: Glenn McClements
Cc:
openmama-dev@...
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

Hi Glenn


My choice is autotools for Linux and MSBuild (VS-project files) on Windows.

I don't see any advantage of using cmake over autotools and I don't understand why need a cross-platform builds when there are only two of them - Linux and Windows.


Regards,

Dmitri Fedorov

Software Architect

Solace
Ottawa, ON Canada

 

Solace accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

On Mon, Oct 17, 2016 at 11:14 AM, Glenn McClements <gmcclements@...> wrote:

Sending on behalf of Frank (mail issues):

 

 

Hi Folks,

 

I have been giving quite a bit of consideration recently to making life easier for setting up new development environments for 3 developer types across all languages (particularly targeting windows as a development platform):

 

·         Users of OpenMAMA

·         Developers of OpenMAMA bridges

·         OpenMAMA contributors

 

I found myself getting repeatedly frustrated with the build system. It’s inflexibility makes many things awkward, and I found my options limited because of having to support all of the build systems we have available (particularly handling build directory structures of third party libraries on windows). Today we have scons for linux, scons for windows (yes – they are fairly separate for some reason), and Visual Studio project files for Windows IDE developers so any time you make a change, you really need to consider all 3.

 

Today in our build infrastructure, we use Scons which is grand, but we already have a lot of things that you have to hack together for scons, but which you actually get out of the box with Cmake like toolchain discovery.

 

I have started playing with it on a small scale and I think it is a really good fit for OpenMAMA because it:

 

·         Generates project files for you so you don’t need to check them into source control – they’ll all get generated from the same definition files

·         They have some library discovery mechanisms built in

·         They have install rules that make sense on both linux and windows

·         It can be used to generate .msi installer executables in conjunction with Wix (!)

·         Allows easy integration with external project types (I’m thinking specifically for C# for this one – mono and visual studio both use msbuild)

·         Takes care of DESTDIR and SONAME functionality which has been requested by package-creators in the past (i.e. for rpm / dpkg)

·         Single build system would simplify CI by not requiring changes in both scons and visual studio on windows

·         It has native IDE integration with many platforms and looks like it might even be on its way for Visual Studio

 

Interestingly, both libevent and qpid proton use cmake, as does almost every other cross-platform C/C++ project that I have stumbled across in the last number of months. With that in mind, I propose that we move our build system to Cmake and end this fun of having to update 3 different built system files every time a new source code file is added.

 

Any opinions either pro or against are welcome. Also if anyone is key to pitch in with the implementation, please chime in!

 

Cheers,

Frank

 

 

 

GLENN MCCLEMENTS

SVP Engineering, Europe

gmcclements@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


Re: Should we make the jump to cmake?

Tom Doust
 

I was wondering if we need to think about multiple build targets – user dev, mama runtime, bridge dev etc.

 

Or is that more complicated than necessary.

 

Also, (and I may just be out of date here because I always just build a minimal subset of OpenMAMA for my dev environment) does the OpenMAMA build still include avis and qpid bridges – if it does, it shouldn’t because I don’t want to have to install 3rd party sdks to be able to do the build.

 

It may be worth thinking about how to structure bridge builds so they can sit along site OpenMAMA and get optionally included in builds if people want them. We would be happy to change our open source bridges to conform to this.

 

Tom

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 24 October 2016 09:39
To: Tom Doust <tom.doust@...>; openmama-dev <openmama-dev@...>
Subject: RE: [Openmama-dev] Should we make the jump to cmake?

 

Yeah you’ve touched on what I said on the other thread there – the libs are actually fine as-is but the headers are definitely missing which are required for bridge development. Honestly I’ve been meaning to go through these header files with a fine toothed comb and see if:

 

A.      These functions are safe enough to just open up in the public headers

B.      The functions are too dangerous to open up

 

If A turns out to be the case, I’m tempted to just make the functions public and be done with it

If B turns out to be the case, I’m still inclined to put the functions in a public header but possibly have an #ifdef BRIDGE inside so they’ll only be available by default to bridge developers.

 

As I recall there are only actually a couple of methods that are required by the bridge that are not public by default so making your life easier might not be as tricky as it sounds. I just raised https://github.com/OpenMAMA/OpenMAMA/issues/234 to track this effort.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Tom Doust
Sent: 24 October 2016 09:26
To: Damian Maguire <dmaguire@...>; Glenn McClements <gmcclements@...>; Dmitri Fedorov <Dmitri.Fedorov@...>; Alpert, Reed <reed.alpert@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

As Reed mentioned we currently use CMake. I think the OpenMAMA devs were considering going there at one point but mysteriously lurched in the direction of Scons within days of Tick42 deciding to use CMake J

 

I am very happy to stick with CMake. I just about understand it and our devs seem to be happy with it.

 

While we are talking about builds, from a bridge development perspective, the output from the current open mama build (headers and libs sdk) is not usable for bridge development. You need some of the headers that are embedded in amongst the C source files (rather than in the various include directories). Its not such a big deal for internal development but when you are contributing bridge code into open source it makes documenting the build process more work.

 

On windows my preference is for one or more sln files and just firing up Visual Studio and hitting “Rebuild All” My experience with msbuild and scripting it is mostly negative both from the point of view of developing scripts and using them. It’s not as good as nmake J

 

Tom

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Damian Maguire
Sent: 18 October 2016 16:28
To: Glenn McClements <gmcclements@...>; Dmitri Fedorov <Dmitri.Fedorov@...>; Alpert, Reed <reed.alpert@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

- Somehow I managed to drop the mailing list responding to this earlier. Sorry about that. 

 

In an effort to avoid bike-shedding this one, I'll say nothing more than I think using CMake is a great idea. 

 

(Side Note: Reed, you're correct that OpenMAMA currently supports OSX as well. CMake integration should make this simpler as well, eliminating the need for the 'Darwin' specific Scons files.)

 

Cheers, 

 

D

 

DAMIAN MAGUIRE 

Senior Sales Engineer 

 

O. +44 289 568 0298  

M. +44 783 584 4770 

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD  

velatradingtech.com | @vela_tt

 

1467620971571_PastedImage


From: openmama-dev-bounces@... <openmama-dev-bounces@...> on behalf of Alpert, Reed via Openmama-dev <openmama-dev@...>
Sent: 17 October 2016 22:44:47
To: Glenn McClements; Dmitri Fedorov
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

Hi,

 

CMake is fine for us, Tick42 uses it now so we have it integrated into our build systems.

Most important is making it easy to change a build feature and do it on one place.

 

Are there other O/S for OpenMAMA – Apple?

 

Thanks,

 

Reed.

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Monday, October 17, 2016 12:00 PM
To: Glenn McClements
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

Hi Glenn


My choice is autotools for Linux and MSBuild (VS-project files) on Windows.

I don't see any advantage of using cmake over autotools and I don't understand why need a cross-platform builds when there are only two of them - Linux and Windows.


Regards,

Dmitri Fedorov

Software Architect

Solace
Ottawa, ON Canada

 

Solace accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

On Mon, Oct 17, 2016 at 11:14 AM, Glenn McClements <gmcclements@...> wrote:

Sending on behalf of Frank (mail issues):

 

 

Hi Folks,

 

I have been giving quite a bit of consideration recently to making life easier for setting up new development environments for 3 developer types across all languages (particularly targeting windows as a development platform):

 

·         Users of OpenMAMA

·         Developers of OpenMAMA bridges

·         OpenMAMA contributors

 

I found myself getting repeatedly frustrated with the build system. It’s inflexibility makes many things awkward, and I found my options limited because of having to support all of the build systems we have available (particularly handling build directory structures of third party libraries on windows). Today we have scons for linux, scons for windows (yes – they are fairly separate for some reason), and Visual Studio project files for Windows IDE developers so any time you make a change, you really need to consider all 3.

 

Today in our build infrastructure, we use Scons which is grand, but we already have a lot of things that you have to hack together for scons, but which you actually get out of the box with Cmake like toolchain discovery.

 

I have started playing with it on a small scale and I think it is a really good fit for OpenMAMA because it:

 

·         Generates project files for you so you don’t need to check them into source control – they’ll all get generated from the same definition files

·         They have some library discovery mechanisms built in

·         They have install rules that make sense on both linux and windows

·         It can be used to generate .msi installer executables in conjunction with Wix (!)

·         Allows easy integration with external project types (I’m thinking specifically for C# for this one – mono and visual studio both use msbuild)

·         Takes care of DESTDIR and SONAME functionality which has been requested by package-creators in the past (i.e. for rpm / dpkg)

·         Single build system would simplify CI by not requiring changes in both scons and visual studio on windows

·         It has native IDE integration with many platforms and looks like it might even be on its way for Visual Studio

 

Interestingly, both libevent and qpid proton use cmake, as does almost every other cross-platform C/C++ project that I have stumbled across in the last number of months. With that in mind, I propose that we move our build system to Cmake and end this fun of having to update 3 different built system files every time a new source code file is added.

 

Any opinions either pro or against are welcome. Also if anyone is key to pitch in with the implementation, please chime in!

 

Cheers,

Frank

 

 

 

GLENN MCCLEMENTS

SVP Engineering, Europe

gmcclements@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


Re: Should we make the jump to cmake?

Frank Quinn <fquinn@...>
 

Yeah you’ve touched on what I said on the other thread there – the libs are actually fine as-is but the headers are definitely missing which are required for bridge development. Honestly I’ve been meaning to go through these header files with a fine toothed comb and see if:

 

A.      These functions are safe enough to just open up in the public headers

B.      The functions are too dangerous to open up

 

If A turns out to be the case, I’m tempted to just make the functions public and be done with it

If B turns out to be the case, I’m still inclined to put the functions in a public header but possibly have an #ifdef BRIDGE inside so they’ll only be available by default to bridge developers.

 

As I recall there are only actually a couple of methods that are required by the bridge that are not public by default so making your life easier might not be as tricky as it sounds. I just raised https://github.com/OpenMAMA/OpenMAMA/issues/234 to track this effort.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Tom Doust
Sent: 24 October 2016 09:26
To: Damian Maguire <dmaguire@...>; Glenn McClements <gmcclements@...>; Dmitri Fedorov <Dmitri.Fedorov@...>; Alpert, Reed <reed.alpert@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

As Reed mentioned we currently use CMake. I think the OpenMAMA devs were considering going there at one point but mysteriously lurched in the direction of Scons within days of Tick42 deciding to use CMake J

 

I am very happy to stick with CMake. I just about understand it and our devs seem to be happy with it.

 

While we are talking about builds, from a bridge development perspective, the output from the current open mama build (headers and libs sdk) is not usable for bridge development. You need some of the headers that are embedded in amongst the C source files (rather than in the various include directories). Its not such a big deal for internal development but when you are contributing bridge code into open source it makes documenting the build process more work.

 

On windows my preference is for one or more sln files and just firing up Visual Studio and hitting “Rebuild All” My experience with msbuild and scripting it is mostly negative both from the point of view of developing scripts and using them. It’s not as good as nmake J

 

Tom

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Damian Maguire
Sent: 18 October 2016 16:28
To: Glenn McClements <gmcclements@...>; Dmitri Fedorov <Dmitri.Fedorov@...>; Alpert, Reed <reed.alpert@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

- Somehow I managed to drop the mailing list responding to this earlier. Sorry about that. 

 

In an effort to avoid bike-shedding this one, I'll say nothing more than I think using CMake is a great idea. 

 

(Side Note: Reed, you're correct that OpenMAMA currently supports OSX as well. CMake integration should make this simpler as well, eliminating the need for the 'Darwin' specific Scons files.)

 

Cheers, 

 

D

 

DAMIAN MAGUIRE 

Senior Sales Engineer 

 

O. +44 289 568 0298  

M. +44 783 584 4770 

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD  

velatradingtech.com | @vela_tt

 

1467620971571_PastedImage


From: openmama-dev-bounces@... <openmama-dev-bounces@...> on behalf of Alpert, Reed via Openmama-dev <openmama-dev@...>
Sent: 17 October 2016 22:44:47
To: Glenn McClements; Dmitri Fedorov
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

Hi,

 

CMake is fine for us, Tick42 uses it now so we have it integrated into our build systems.

Most important is making it easy to change a build feature and do it on one place.

 

Are there other O/S for OpenMAMA – Apple?

 

Thanks,

 

Reed.

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Monday, October 17, 2016 12:00 PM
To: Glenn McClements
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Should we make the jump to cmake?

 

Hi Glenn


My choice is autotools for Linux and MSBuild (VS-project files) on Windows.

I don't see any advantage of using cmake over autotools and I don't understand why need a cross-platform builds when there are only two of them - Linux and Windows.


Regards,

Dmitri Fedorov

Software Architect

Solace
Ottawa, ON Canada

 

Solace accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

On Mon, Oct 17, 2016 at 11:14 AM, Glenn McClements <gmcclements@...> wrote:

Sending on behalf of Frank (mail issues):

 

 

Hi Folks,

 

I have been giving quite a bit of consideration recently to making life easier for setting up new development environments for 3 developer types across all languages (particularly targeting windows as a development platform):

 

·         Users of OpenMAMA

·         Developers of OpenMAMA bridges

·         OpenMAMA contributors

 

I found myself getting repeatedly frustrated with the build system. It’s inflexibility makes many things awkward, and I found my options limited because of having to support all of the build systems we have available (particularly handling build directory structures of third party libraries on windows). Today we have scons for linux, scons for windows (yes – they are fairly separate for some reason), and Visual Studio project files for Windows IDE developers so any time you make a change, you really need to consider all 3.

 

Today in our build infrastructure, we use Scons which is grand, but we already have a lot of things that you have to hack together for scons, but which you actually get out of the box with Cmake like toolchain discovery.

 

I have started playing with it on a small scale and I think it is a really good fit for OpenMAMA because it:

 

·         Generates project files for you so you don’t need to check them into source control – they’ll all get generated from the same definition files

·         They have some library discovery mechanisms built in

·         They have install rules that make sense on both linux and windows

·         It can be used to generate .msi installer executables in conjunction with Wix (!)

·         Allows easy integration with external project types (I’m thinking specifically for C# for this one – mono and visual studio both use msbuild)

·         Takes care of DESTDIR and SONAME functionality which has been requested by package-creators in the past (i.e. for rpm / dpkg)

·         Single build system would simplify CI by not requiring changes in both scons and visual studio on windows

·         It has native IDE integration with many platforms and looks like it might even be on its way for Visual Studio

 

Interestingly, both libevent and qpid proton use cmake, as does almost every other cross-platform C/C++ project that I have stumbled across in the last number of months. With that in mind, I propose that we move our build system to Cmake and end this fun of having to update 3 different built system files every time a new source code file is added.

 

Any opinions either pro or against are welcome. Also if anyone is key to pitch in with the implementation, please chime in!

 

Cheers,

Frank

 

 

 

GLENN MCCLEMENTS

SVP Engineering, Europe

gmcclements@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC

381 - 400 of 2305