On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly <mingw.android@...> 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
> 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
> 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
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
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:
Thank you. I appreciate the effort.
> Here are some free resources for autotools:
> There's also a book you can buy:
Perhaps you'll make an autotools connoisseur out of me yet.
> Finally, I recommend console2 for any MSYS work. It's really good.
> Good luck,
Thank you. I appreciate everyone's suggestions and help.