Re: question about building on Windows


Damian Maguire <d.maguire@...>
 

For what it’s worth, I agree with Frank’s take here. I was looking at some of Dmitri’s questions last night and had to modify my own test environment to be able to recreate some of them – there’s clearly just too many factors for a project like ours to handle sensibly.

 

A side note on this – where we’re having to do something particularly unusual (such as copying header files around, or modifying includes), it might be beneficial for us to take the time to understand why. If it’s a problem with the way we use the libraries, that should probably be something we fix in OpenMAMA; If it’s a problem with the third party, we should probably see if we can either commit a fix upstream to the projects themselves, or at least raise a bug with them to see if it can be resolved (something we can point to the next time someone asks). Making our own changes and hiding them away is probably not the spirit of open source collaboration we’re going for.

 

Cheers,

 

D

 

Damian Maguire, Senior Sales Engineer

Mobile: +44 7835 844 770

Desk (Direct): +4428 9568 0298

Adelaide Exchange | 24-26 Adelaide Street | Belfast | UK | BT2 8GD

 

SR.LABS Proven High Speed Electronic Trading Solutions

 

 

From: <openmama-dev-bounces@...> on behalf of Dmitri Fedorov <dfedorov.solace@...>
Date: Tuesday, May 10, 2016 at 11:06 PM
To: Frank Quinn <fquinn.ni@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] question about building on Windows

 

Hi Frank,

 

This approach makes sense to me because my goal from the beginning was to assign proper values to EVENT_HOME, PROTON_HOME and AVIS_HOME.

 

Here is a branch I fixed to build with VS2015, I did not try it on other platforms (and I won't):

 

I'm not done yet :-)

 

Cheers

Dmitri

 

Solace Systems 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 10 May 2016 at 16:50, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,

Honestly, the more I deal with these issues (which seem to come up in a different form every time someone tries to build on windows), the more I think this step by step thing that we do for dependencies needs a serious descope.

There are too many moving parts and I think OpenMAMA is trying to do too much: between 3rd party code, windows SDKs, VS versions, release vs debug builds and architectures. Instead I think we should list the library and header locations we expect for the dependency along with high level instructions on how to build (I.e build using solution files).

The issue you hit there is literally nothing to do with OpenMAMA - its a bug with libevent in your build stack - so rather than update our documentation to support every possible permutation, or specify one which we still need to constantly update, I think we should just keep it vague. I'd be interested to see if the community has any thoughts on this too.

Really the only things that are relevant to OpenMAMA are those directory paths.

Cheers,
Frank

 

On Tue, 10 May 2016 21:06 Dmitri Fedorov, <dfedorov.solace@...> wrote:

I've fixed the error, no big deal, my intention here is to understand if a) I'm not following instructions properly or b) the instructions need to be updated.

You're the only person who can tell me if this is the case a)

If this is the case b) then I'll figure it out, fix it up and share the instructions that work.

 

​Cheers

Dmitri

 

On 10 May 2016 at 15:54, Frank Quinn <fquinn.ni@...> wrote:

*sigh* most recent response was from memory rather than anything else. When I get a chance to look I can verify. It reads like you could just comment out the duplicate definition though.

 

On Tue, 10 May 2016 19:45 Dmitri Fedorov, <dfedorov.solace@...> wrote:

Same error using the VS project file:

1>  event.c

1>c:\program files (x86)\windows kits\10\include\10.0.10240.0\ucrt\time.h(39): error C2011: 'timespec': 'struct' type redefinition

1>  c:\projects\ext\libevent-release-1.4.15-stable\compat\sys\_libevent_time.h(52): note: see declaration of 'timespec'

 

I'm going to try changing 1.4.15 project file, if you confirm that looks like VS2015 specific issue and you didn't have these problems on version VS2010/2012/2013

 


Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems 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 10 May 2016 at 14:35, Frank Quinn <fquinn.ni@...> wrote:

Don't use nmake use the libevent 1.x project file instead. That will build libevent.lib

 

On Tue, 10 May 2016 19:31 Dmitri Fedorov, <dfedorov.solace@...> wrote:

Frank,

 

Now I'm puzzled by the other dependency: libevent.

 

The OpenMAMA Wiki page you referred to suggests to build 1.4.x as libevent_code.lib, but openmama\mama\c_cpp\src\c\bridge\avis\avis.vcxproj refers to libevent.lib, how is it going to work?

 

What version of libevent do I need to build: 1.4.15 or 2.0.22?

 

It looks to me that the recommended version 1.4.X fails be build, OpenMAMA refers to the library that is not what's being build.

 

I was able to build 2.0.22 with "nmake /F Makefile.nmake libevent_core.lib", but I cannot build 1.4.15:

 

C:\Projects\ext\libevent-release-1.4.15-stable>nmake /F Makefile.nmake libevent_core.lib

Microsoft (R) Program Maintenance Utility Version 14.00.23506.0

Copyright (C) Microsoft Corporation.  All rights reserved.

        cl /Iinclude /Icompat /IWIN32-Code /DWIN32 /DHAVE_CONFIG_H /I. /Ox /W3 /wd4996 /nologo /c ev

ent.c

event.c

C:\Program Files (x86)\Windows Kits\10\include\10.0.10586.0\ucrt\time.h(39): error C2011: 'timespec'

: 'struct' type redefinition

compat\sys/_libevent_time.h(52): note: see declaration of 'timespec'

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.EXE"' : r

eturn code '0x2'

Stop.

 

Thanks

Dmitri

 

On 9 May 2016 at 14:53, Frank Quinn <f.quinn@...> wrote:

Hi Dmitri,

 

Looks like a C&P error from when this document was pulled across – see original instructions here:

 

http://wiki.openmama.org/index.php/Building_Libevent

 

Last time I built on windows though I don’t think I needed this step anymore, so maybe that was only for Visual Studio 2008 which is what I was using when I originally created those instructions.

 

Try going ahead without it and let me know how you get on so I can update documentation Instead try building with the libevent solution file in the WIN32-Prj subdirectory.


Cheers,

Frank

 

Frank Quinn, Principal Software Engineer
Tel: +44 (0) 28 9568 0209 (Ext: 3592)
24-26 Adelaide Street, Belfast, Northern Ireland, BT2 8GD
www.srtechlabs.com

SR.LABS Proven High Speed Electronic Trading Solutions

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 09 May 2016 19:41
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] question about building on Windows

 

In Wiki page on building under Windows for libevent:

 

 

There is the following sentence I have a question about, please:

 

> At this point there is an additional step which is required in order to work

> around a bug in the libevent libraries. Once the nmake command has

> completed, navigate to the ''include'' directory. Open the file ''event.h'', and

> add #include along with the other includes (yes - after compilation... don't

> ask). When complete, save the file and exit.

 

I'm puzzled by this instruction:

> add #include along with the other includes

 

Could someone explain it to me, please?

Add where? Add what, an empty #include?

What "other" includes? 

 

Thank you in advance.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems 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.


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. SR Labs LLC

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

 

 

 


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. SR Labs LLC

Join Openmama-dev@lists.openmama.org to automatically receive all group messages.