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

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

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 3^rd 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

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

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

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

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

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

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

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

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

Thanks Tom,

You can actually build a bridge fine without having to rebuild OpenMAMA, but you do need to point your project to the source of OpenMAMA for a few internal header files which aren’t included in the distribution, but which bridge folks need (adding a project reference probably fixed this for you). You can check out OpenMAMA-zmq for an example of how to do it (if you’re interested).

Appreciate the offer of assistance – I would welcome any warning reduction changes you could contribute, or failing that, just verifying the changes that I’ll be putting in over the coming months to make sure I don’t break your stuff would be hugely helpful. With the new instructions it should be much easier to set up a build environment now than it was before.

Cheers,

Frank

Hi Frank

I’ve not found it possible to do bridge development (on windows anyway) without building OpenMAMA J It may be possible though. I have just taken a path of least resistance.

Let us know if we can be any help

Tom

Hi Folks,

I have said many times that we need to focus more on our Windows environment and bring it up to speed with the linux development experience. With that in mind, I have decided to bite the bullet and stop using Fedora as my primary workstation and go cold-turkey with windows (gasp).

One of the first stumbling blocks that I hit was dependency generation and the series of in-source builds and hacking of third party files which are needed to let windows builds work. As a result of this, I have just submitted changes into next which re-organizes the directory structure the build systems expect from the OpenMAMA dependencies on windows to be more sane, but note that it will break existing build environments, so if you compile your own OpenMAMA, you’ll need to shuffle around your dependencies a little to work with the latest code from ‘next’.

Note: Build environment is only broken for people who are compiling their own OpenMAMA libraries (i.e. OpenMAMA contributors). Users and even bridge developers don’t need to take action

The directory structure aligns with cmake install targets (which all our dependencies now seem to use) and its standard distribution methods. Details on how to set up the new expected directory structure and build OpenMAMA can be found here: https://github.com/OpenMAMA/OpenMAMA/wiki/Build-Instructions. I have also added specialist instructions for RedHat based systems as well as Debian based systems.

The nice thing about this set of changes is that if you follow those instructions, it’ll “just work” (I tried on a clean workstation to verify). Solution files and scons builds alike will build out of the box without requiring enormous command lines to point to non-standard directory structures because the third party library doesn’t have standard solution files which support (for example) 64-bit builds. If anyone hits any problems, please raise an issue because I want those instructions to be rock solid.

This follows other changes which have landed on OpenMAMA’s next branch within the last few weeks which are working towards the common goal of making Windows development convenient including:

·         Changes to allow Unit tests to compile and run on Windows

·         Fix submitted to prevent Unit Tests crashing on windows in mamaDateTime code

·         Added ability to generate installers as part of the release process

So just to keep everyone updated, “Operation: Windows Love” is well underway. There is still a number of related tasks which I want to get completed before the next OpenMAMA release (expected early 2017) which will likely be speckled among the other roadmap items we are aiming to get completed before the next release:

·         Elimination of build warnings on windows

·         Unit tests all running and passing on windows

·         Unit tests integrated with CI on windows

Cheers,

Frank

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

Hi Frank

I’ve not found it possible to do bridge development (on windows anyway) without building OpenMAMA J It may be possible though. I have just taken a path of least resistance.

Let us know if we can be any help

Tom

Hi Folks,

I have said many times that we need to focus more on our Windows environment and bring it up to speed with the linux development experience. With that in mind, I have decided to bite the bullet and stop using Fedora as my primary workstation and go cold-turkey with windows (gasp).

One of the first stumbling blocks that I hit was dependency generation and the series of in-source builds and hacking of third party files which are needed to let windows builds work. As a result of this, I have just submitted changes into next which re-organizes the directory structure the build systems expect from the OpenMAMA dependencies on windows to be more sane, but note that it will break existing build environments, so if you compile your own OpenMAMA, you’ll need to shuffle around your dependencies a little to work with the latest code from ‘next’.

Note: Build environment is only broken for people who are compiling their own OpenMAMA libraries (i.e. OpenMAMA contributors). Users and even bridge developers don’t need to take action

The directory structure aligns with cmake install targets (which all our dependencies now seem to use) and its standard distribution methods. Details on how to set up the new expected directory structure and build OpenMAMA can be found here: https://github.com/OpenMAMA/OpenMAMA/wiki/Build-Instructions. I have also added specialist instructions for RedHat based systems as well as Debian based systems.

The nice thing about this set of changes is that if you follow those instructions, it’ll “just work” (I tried on a clean workstation to verify). Solution files and scons builds alike will build out of the box without requiring enormous command lines to point to non-standard directory structures because the third party library doesn’t have standard solution files which support (for example) 64-bit builds. If anyone hits any problems, please raise an issue because I want those instructions to be rock solid.

This follows other changes which have landed on OpenMAMA’s next branch within the last few weeks which are working towards the common goal of making Windows development convenient including:

·         Changes to allow Unit tests to compile and run on Windows

·         Fix submitted to prevent Unit Tests crashing on windows in mamaDateTime code

·         Added ability to generate installers as part of the release process

So just to keep everyone updated, “Operation: Windows Love” is well underway. There is still a number of related tasks which I want to get completed before the next OpenMAMA release (expected early 2017) which will likely be speckled among the other roadmap items we are aiming to get completed before the next release:

·         Elimination of build warnings on windows

·         Unit tests all running and passing on windows

·         Unit tests integrated with CI on windows

Cheers,

Frank

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

Hi Folks,

I have said many times that we need to focus more on our Windows environment and bring it up to speed with the linux development experience. With that in mind, I have decided to bite the bullet and stop using Fedora as my primary workstation and go cold-turkey with windows (gasp).

One of the first stumbling blocks that I hit was dependency generation and the series of in-source builds and hacking of third party files which are needed to let windows builds work. As a result of this, I have just submitted changes into next which re-organizes the directory structure the build systems expect from the OpenMAMA dependencies on windows to be more sane, but note that it will break existing build environments, so if you compile your own OpenMAMA, you’ll need to shuffle around your dependencies a little to work with the latest code from ‘next’.

Note: Build environment is only broken for people who are compiling their own OpenMAMA libraries (i.e. OpenMAMA contributors). Users and even bridge developers don’t need to take action

The directory structure aligns with cmake install targets (which all our dependencies now seem to use) and its standard distribution methods. Details on how to set up the new expected directory structure and build OpenMAMA can be found here: https://github.com/OpenMAMA/OpenMAMA/wiki/Build-Instructions. I have also added specialist instructions for RedHat based systems as well as Debian based systems.

The nice thing about this set of changes is that if you follow those instructions, it’ll “just work” (I tried on a clean workstation to verify). Solution files and scons builds alike will build out of the box without requiring enormous command lines to point to non-standard directory structures because the third party library doesn’t have standard solution files which support (for example) 64-bit builds. If anyone hits any problems, please raise an issue because I want those instructions to be rock solid.

This follows other changes which have landed on OpenMAMA’s next branch within the last few weeks which are working towards the common goal of making Windows development convenient including:

·         Changes to allow Unit tests to compile and run on Windows

·         Fix submitted to prevent Unit Tests crashing on windows in mamaDateTime code

·         Added ability to generate installers as part of the release process

So just to keep everyone updated, “Operation: Windows Love” is well underway. There is still a number of related tasks which I want to get completed before the next OpenMAMA release (expected early 2017) which will likely be speckled among the other roadmap items we are aiming to get completed before the next release:

·         Elimination of build warnings on windows

·         Unit tests all running and passing on windows

·         Unit tests integrated with CI on windows

Cheers,

Frank

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