Re: [Mingw-w64-public] [Mingw-users] Thoughts on how to build a linux / visual studio project (QuickFIX) with mingw

[Kai T. <kti...@go...>]

2013/1/6 Ruben Van Boxem <van...@gm...>:
> Op 6 jan. 2013 02:21 schreef "JonY" <jo...@us...> 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 handicapped.
>>
>> > To Ruben's comment:  Is there some way I can check whether
>> > the configure script claims to support mingw?  Should I expect
>> > the character string for the host (e.g.,  "i686-w64-mingw32") to
>> > reside somewhere in the script itself?  Is there some "database"
>> > file of supported hosts used by the scripts that I could search
>> > for variations of "mingw"?  I'd like to have some expectation that
>> > the configure script supports mingw before I go hunt down a
>> > linux system or unix emulator.
>> >
>>
>> It is always there, all configure scripts will check for all known
>> platforms, whether it will actually work depends on how it was written.
>> Since you don't have much experience in autotools, your best bet is to
>> just run it and see what happens.
>>
>> > As for Peter's suggestion, I will check out CodeLite.  If it doesn't
>> > look too painful, I'll try translating the solutions file into a
>> > makefile.
>> > 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 up with windows threading and winsock.
>> > (Just a hope.)
>>
>> Ugh, that was painful to read. What part of configure implies pthreads
>> and posix sockets? GCC source too has configure, does it make pthread a
>> requirement? No.
>
> Well, think about what you're saying... GCC autotools have a bunch of checks
> for mingw that make the build use windows specific sources. There's bound to
> be some Unix specific and windows specific source files in QuickFix. If the
> autotools wasn't written with that in mind, you're screwed. Autotools isn't
> a one stop ticket to a full cross-platform build without some modification.
> Take off your pink glasses, autotools isn't the holy grail. He might well
> run into the wrong source files (and thus Unix stuff like sockets and
> pthreads) being used in the autotools build.
>
> Ruben

Hmm, what in hell has any build-environment to do with venture
specific target-files? Any good build-environment provides the ability
to the programmer to specify special-case sources, allow
cross-compilation configure OOTB, providing features to check and test
for runtime-environment features, etc.  So in any case you need to
port venture's source and build-environment to a specific target
manually.
So the question is not that much *which* build-environment you shall
choose, it is more *what* environment is required for my needs.  For
example, if I want that my venture can be built on cmd on Windows -
maybe even with VC - then I should choose a build-environment
supporting that best (like CMake).  If I want to built mainly on
POSIX-environments, or want the ability of cross-compilation then
autotools might be a good choice.

Kai