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 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

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