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.





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!








SVP Engineering, Europe



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.