Hello Ray!
On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly wrote:
> I've had a quick look at the source code and it's littered with stuff like:
>
> #ifdef _MSC_VER
> #include
Yes, this is indeed the case. but this is actually good because
there is (appears to be) a single cross-platform code bas
On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly wrote:
> I've had a quick look at the source code and it's littered with stuff like:
Kudos for looking at the source! :)
> #ifdef _MSC_VER
> #include
> ...
>
> So the fact is that the code itself conflates Windows builds with the
> MSVC compiler vi
Yes,
That's precisely what I meant by the word "conflates".
On Sun, Jan 6, 2013 at 4:41 PM, Earnie Boyd
wrote:
> On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly wrote:
>> I've had a quick look at the source code and it's littered with stuff like:
>>
>> #ifdef _MSC_VER
>
> Which is the wrong MACRO
On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly wrote:
> I've had a quick look at the source code and it's littered with stuff like:
>
> #ifdef _MSC_VER
Which is the wrong MACRO to detect Windows build. It is the right
MACRO to detect using MSVC.
> #include
> ...
>
> So the fact is that the code
I've had a quick look at the source code and it's littered with stuff like:
#ifdef _MSC_VER
#include
...
So the fact is that the code itself conflates Windows builds with the
MSVC compiler via _MSC_VER
..you could in theory do something awful like ./configure
CFLAGS="-D_MSC_VER=" but the confla
On 1/6/2013 21:38, Ruben Van Boxem wrote:
>
> I'll try to clarify my point one more time: yes it is possible in autotools
> to exclude code depending on configure. But that is not an autotools
> specific feature. Code and/or build systems not meant to be used on
> platforms that weren't in the dev
Hi Ruben (and Peter) -
First, thanks to everyone for their comments. This discussion has
been very informative and helpful.
Before commenting inline, below, please let me semi-hijack this
section of the thread with a comment to Peter: I've downloaded
(but not yet installed) CodeLite, and have b
2013/1/6 JonY
> On 1/6/2013 20:55, Ruben Van Boxem wrote:
> >
> > To get this thread back on-topic and to prove my point (even with
> autotools
> > if you didn't have a platform in mind it probably won't work out of the
> > box), I tried the quickfix autotools and got (the half-expected):
> >
> >
On 1/6/2013 20:55, Ruben Van Boxem wrote:
>
> To get this thread back on-topic and to prove my point (even with autotools
> if you didn't have a platform in mind it probably won't work out of the
> box), I tried the quickfix autotools and got (the half-expected):
>
> libtool: compile: x86_64-w64
2013/1/6 JonY
> On 1/6/2013 18:54, Kai Tietz wrote:
>
> I'm thinking (perhaps wrongly) that if I start with the unix configure
> script, I'll be more likely to get bumped over into unix-style,
> pthreads
> and posix sockets land, where if I start on the visual studio side, I
>
On 1/6/2013 18:54, Kai Tietz wrote:
I'm thinking (perhaps wrongly) that if I start with the unix configure
script, I'll be more likely to get bumped over into unix-style, pthreads
and posix sockets land, where if I start on the visual studio side, I
might be more likely to end
2013/1/6 Kai Tietz
> 2013/1/6 Ruben Van Boxem :
> > Op 6 jan. 2013 02:21 schreef "JonY" het
> > volgende:
> >
> >
> >>
> >> On 1/6/2013 05:49, K. Frank wrote:
> >> > I don't currently have msys or a unix emulator set up. So the
> >> > suggestion to try out the configure script "just to see" inv
2013/1/6 Ruben Van Boxem :
> Op 6 jan. 2013 02:21 schreef "JonY" het
> volgende:
>
>
>>
>> On 1/6/2013 05:49, K. Frank wrote:
>> > I don't currently have msys or a unix emulator set up. So the
>> > suggestion to try out the configure script "just to see" involves
>> > a little more work than just
Op 6 jan. 2013 02:21 schreef "JonY" het
volgende:
>
> On 1/6/2013 05:49, K. Frank wrote:
> > I don't currently have msys or a unix emulator set up. So the
> > suggestion to try out the configure script "just to see" involves
> > a little more work than just trying it out.
> >
>
> Feels handicappe
On 1/6/2013 05:49, K. Frank wrote:
> I don't currently have msys or a unix emulator set up. So the
> suggestion to try out the configure script "just to see" involves
> a little more work than just trying it out.
>
Feels handicapped.
> To Ruben's comment: Is there some way I can check whether
Hello Ruben and All!
On Sat, Jan 5, 2013 at 5:36 AM, Ruben Van Boxem
wrote:
> 2013/1/4 K. Frank
>
>> Hi Lists!
>>
>> What are people's thoughts on porting a linux / visual studio
>> project to mingw and / or mingw-w64?
>>
>> I had asked earlier whether anyone had built QuickFIX with mingw
>> and
2013/1/4 K. Frank
> Hi Lists!
>
> What are people's thoughts on porting a linux / visual studio
> project to mingw and / or mingw-w64?
>
> I had asked earlier whether anyone had built QuickFIX with mingw
> and / or mingw-w64. I conclude from the relative silence that mingw
> is not directly supp
> Date: Thu, 3 Jan 2013 22:47:58 -0500
> From: "K. Frank"
>
> I see three ways to proceed:
>
> 1) Start with the actual source (i.e., .cpp files, etc.) and put
> together my own mingw32-make-compatible makefile. I think
> this should be relatively straightforward, but tedious, and would
> presu
On 1/4/2013 11:47, K. Frank wrote:
>
> So, I'm not asking for a recipe to build QuickFIX in particular.
> Rather, I'm hoping for some wisdom on how to port a relatively
> clean, cross-platform (joint linux / visual studio) project to mingw,
> and on what tricky points I might encounter when doing
Hi Lists!
What are people's thoughts on porting a linux / visual studio
project to mingw and / or mingw-w64?
I had asked earlier whether anyone had built QuickFIX with mingw
and / or mingw-w64. I conclude from the relative silence that mingw
is not directly supported by the QuickFIX project, and
20 matches
Mail list logo
