Hello Ray! On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly <[email protected]> wrote: > I've had a quick look at the source code and it's littered with stuff like: > > #ifdef _MSC_VER > #include <Winsock2.h>
Yes, this is indeed the case. but this is actually good because there is (appears to be) a single cross-platform code base in which the unix / windows differences are reasonably well encapsulated in #ifdef's. > ... > 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=<SOMETHING_VALID>" but the conflation will still > bite you due to things like: > > #ifdef _MSC_VER > #pragma warning( disable : 4503 4355 4786 4290 ) But, indeed, as you point out compiler differences (that is msvc vs., e.g., mingw, as opposed to os differences) are also controlled by the same #ifdef's. I'm cool with that. I largely understand what I'm looking at and I'm not expecting the project to build out of the box or compile without modification. I'm happy to tweak the source files and #ifdef's and I think I know how to do so. Anticipating Earnie's comment, it sounds like I will change the #ifdef's for windows api stuff to _WIN32 and leave the msvc-specific stuff in _MSC_VER #ifdef's. Leaving autotools out of it, my presumption is that if I run mingw32-make on a plain-vanilla, hand-written makefile, _WIN32 will be defined for me automatically, and that _MSC_VER will be left undefined. (Please let me know if I have these details right, because I will probably end up going down this path.) > ...so no matter what build system you try to add or improve, a lot of > source files will have to be altered to remove the conflation. > Usually, it would end being lots of orthogonal > header/declaration/function and library tests, to unconflate using > autotools for example the Winsock2.h include would be compile-guarded > instead with #if HAVE_WINSOCK2_H > > My personal opinion is that the only sensible way to proceed is to use > autotools because: > 1. Autotools is/are fine when you get used to them, yes there's some > stuff to learn (see the resources I link to later), but it's > transferable knowledge. But -- and I believe this was Ruben's point -- autotools won't tweak the source code for me. Although less reusable, for a one-off project going in and fixing the source code by hand to work with mingw is no more work than fixing the source code to work with autotools. Or am I wrong about this? > 2. Hand writing a Makefile is a lot of one-off-work for any single project. Ah, but I have the strength of ten (because my heart is pure). On a more serious note, once I identify which source is used to build the core QuickFIX library and what macros may need to be defined, I don't think setting up the makefile will be very hard. It appears to be a one-step (two, if you count linking) build process. I don't see any, for example, Qt, and although I do see a hint of lex / yacc, I don't think it enters into the build process. If I were bloody-minded about it, I bet I could set up a windows cmd .bat file with a single giant g++ command in it to do the build. (But, since I'm not bloody-minded, I don't plan to do this ...) > 3. An autotooling patch to support MSYS builds might benefit the > QuickFix project if they were willing to accept it (you could ask them > beforehand). Well, yes. But let me see if I can make any useful progress first ... > You mentioned CodeLite. This is irrelevant to this discussion; AFAICT, > it's an IDE and a pretty basic one at that. If you wanted to use a C++ > IDE I'd go for Qt Creator because it's got an autotools plugin (it > worked fairly well when I tried it). I'm a big fan of Qt Creator > though. The relevance of CodeLite is based on Peter's comment (that might have been directly only to the mingw-users list) that CodeLite can translate a visual-studio solutions file to a gcc-style makefile. I have installed CodeLite. I see brief hints in the documentation, and suggestive entries in CodeLite's gui menus that this should be possible, but I haven't figured out how to do it yet. (Peter, if you're around, I've re-copied this post to the mingw list. My sticking point is that I seem to be able to import a msvc solutions file into a CodeLite workspace, and I seem to be able to export a makefile from a CodeLite project, but I haven't been able to get the workspace (or at least the solutions file in it) linked to the project, so the makefile I export is trivial. I do think I created the project in the workspace, but what do I know ... ? Any further suggestions would be most welcome.) > You said that you didn't have MSYS and didn't want hassle setting it > up. I made a script to bootstrap a MinGW-w64 and MSYS environment that > might work for you: > https://raw.github.com/mingwandroid/crucifixion-freedom/master/scripts/windows/BootstrapMinGW64.vbs Thank you. I appreciate the effort. > Here are some free resources for autotools: > http://sourceware.org/autobook/ > http://www.lrde.epita.fr/~adl/dl/autotools.pdf > http://www.flameeyes.eu/autotools-mythbuster/ > https://www.gnu.org/software/autoconf-archive/ > > There's also a book you can buy: > http://nostarch.com/autotools.htm Perhaps you'll make an autotools connoisseur out of me yet. > Finally, I recommend console2 for any MSYS work. It's really good. > http://sourceforge.net/projects/console/ > > Good luck, > > Ray. > ... Thank you. I appreciate everyone's suggestions and help. K. Frank ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
