2013/1/6 Ruben Van Boxem <vanboxem.ru...@gmail.com>: > Op 6 jan. 2013 02:21 schreef "JonY" <jo...@users.sourceforge.net> 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 ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
