From: K. F. <kfr...@gm...> - 2013-01-04 03:48:05
|
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 that no one has really tried or succeeded in building QuickFIX with mingw. So I thought I might try doing so myself. 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 presumably represent duplicated effort. 2) Try to translate a visual studio solution file into a makefile. First, I don't know how to go about doing so (solution files are rather different than makefiles), and second, doing so might trigger visual-studio-specific features (e.g., .stdafx.h files). 3) Try to run the linux configure script -- maybe with msys -- to get a mingw32-make-compatible makefile, or at least a makefile than can be used as a starting point. My concern here is that doing so would put the configure script into "linux mode" and would trigger the use of various linux-specific code (e.g., posix sockets). In a sense getting QuickFIX to build with mingw shouldn't be too hard. It is already written in relatively portable, non-microsofty c++ (because it builds on the linux side), but can be built as a native windows application (because it builds on the visual studio side). My problem is that the build process is encoded, on the one hand, in automake "configure && make" scripts, and on the other hand, in visual studio solution files. QuickFIX offers both linux and windows distributions. The source code in the two distributions is identical. (At least as far as I can tell. It's certainly nearly identical.) The linux / windows differences reside in #ifdef'ed sections of the joint code base, and the most notable differences I have come across are (not surprisingly) posix sockets vs. winsock. 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 so. Thanks for any advice. K. Frank |
From: JonY <jo...@us...> - 2013-01-04 09:54:19
Attachments:
signature.asc
|
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 so. > > Thanks for any advice. > mingw32-make is NOT msys compatible, it is NOT the same as regular make or make in Linux. mingw32-make is designed to run under cmd, consequently Makefiles for the other make is incompatible, do not mix or confuse the 2. If it is just a straight "compile all sources and link them together", a simple Makefile will do. These makefiles tend to have less flexibility and will have cruft building over time as features are added. If you need more advanced features like detecting compiler capabilities and/or cross compile from Linux to Windows etc, use autotools, accept no other substitutes. Since you already have autotools, it make sense to work from there for mingw support rather than yet another parallel build system. |
From: Eli Z. <el...@gn...> - 2013-01-04 09:04:35
|
> Date: Thu, 3 Jan 2013 22:47:58 -0500 > From: "K. Frank" <kfr...@gm...> > > 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 > presumably represent duplicated effort. > > 2) Try to translate a visual studio solution file into a makefile. > First, I don't know how to go about doing so (solution files are > rather different than makefiles), and second, doing so might > trigger visual-studio-specific features (e.g., .stdafx.h files). > > 3) Try to run the linux configure script -- maybe with msys -- to > get a mingw32-make-compatible makefile, or at least a makefile > than can be used as a starting point. My concern here is that > doing so would put the configure script into "linux mode" and > would trigger the use of various linux-specific code (e.g., posix > sockets). The choice depends on your goals. The first 2 alternatives will yield a MinGW specific Makefile and build procedures, which will then need to be maintained separately. In my experience, the result is playing the never-ending catch-up game with the mainstream, which is almost always lost due to insufficient resources -- people who initially did that lose interest and/or move on, and the MinGW build procedure is left to bit-rot in some subdirectory. However, if all you want is a one-time success, this might be good enough for you, and it probably is easier in the short run. If your goal is to make QuickFIX support MinGW in the long run, I would suggest the 3rd way. It, too, requires maintenance, because new features introduced into the package need sometimes to be "MinGW-ized" to work correctly on Windows (or sometimes disabled). But the amount of such maintenance is much smaller, and it is usually met with more sympathy by the upstream developers, because you suggest changes in files and methods they understand very well, not in some back-yard stuff which just uses their package as storage. > In a sense getting QuickFIX to build with mingw shouldn't be too > hard. It is already written in relatively portable, non-microsofty > c++ (because it builds on the linux side), but can be built as a > native windows application (because it builds on the visual studio > side). > > My problem is that the build process is encoded, on the one hand, > in automake "configure && make" scripts, and on the other hand, > in visual studio solution files. > > QuickFIX offers both linux and windows distributions. The source > code in the two distributions is identical. (At least as far as I can > tell. It's certainly nearly identical.) The linux / windows differences > reside in #ifdef'ed sections of the joint code base, and the most > notable differences I have come across are (not surprisingly) posix > sockets vs. winsock. What you need to do is run the configure script using MSYS, and then analyze the config.h header file created by the script. Compare it with the same file provided by the VS build procedure, then make changes to configure.ac (or whatever is its name) and its components to yield the same in the MinGW build. IOW, you need to have those #ifdef's fire exactly as they do in the current VS build, by arranging for the corresponding macros be defined as appropriate. In addition, there could be Windows specific source files that need to be used; in that case, you will need to modify Makefile.in or Makefile.am to that effect. You will have to read about Autoconf and Automake (if you don't already know how to use them) and use their facilities. But that is not very complicated, and you will find a lot of real-life examples in the package that will tell you how to do that. |
From: Ruben V. B. <van...@gm...> - 2013-01-05 10:36:31
|
2013/1/4 K. Frank <kfr...@gm...> > 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 that no one > has really tried or succeeded in building QuickFIX with mingw. > > So I thought I might try doing so myself. > > 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 > presumably represent duplicated effort. > > 2) Try to translate a visual studio solution file into a makefile. > First, I don't know how to go about doing so (solution files are > rather different than makefiles), and second, doing so might > trigger visual-studio-specific features (e.g., .stdafx.h files). > > 3) Try to run the linux configure script -- maybe with msys -- to > get a mingw32-make-compatible makefile, or at least a makefile > than can be used as a starting point. My concern here is that > doing so would put the configure script into "linux mode" and > would trigger the use of various linux-specific code (e.g., posix > sockets). > If it's a decent configure script, passing --host=i686-w64-mingw32 or --host=x86_64-w64-mingw32 should work just fine. If there's a configure script present, try using that. It cannot be used to get a mingw32-make compatible makefile. > > In a sense getting QuickFIX to build with mingw shouldn't be too > hard. It is already written in relatively portable, non-microsofty > c++ (because it builds on the linux side), but can be built as a > native windows application (because it builds on the visual studio > side). > > My problem is that the build process is encoded, on the one hand, > in automake "configure && make" scripts, and on the other hand, > in visual studio solution files. > > QuickFIX offers both linux and windows distributions. The source > code in the two distributions is identical. (At least as far as I can > tell. It's certainly nearly identical.) The linux / windows differences > reside in #ifdef'ed sections of the joint code base, and the most > notable differences I have come across are (not surprisingly) posix > sockets vs. winsock. > > 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 so. > > Thanks for any advice. > > > K. Frank > > > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: K. F. <kfr...@gm...> - 2013-01-05 21:49:27
|
Hello Ruben and All! On Sat, Jan 5, 2013 at 5:36 AM, Ruben Van Boxem <van...@gm...> wrote: > 2013/1/4 K. Frank <kfr...@gm...> > >> 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 that no one >> has really tried or succeeded in building QuickFIX with mingw. >> ... >> 3) Try to run the linux configure script -- maybe with msys -- to >> get a mingw32-make-compatible makefile, or at least a makefile >> than can be used as a starting point. My concern here is that >> doing so would put the configure script into "linux mode" and >> would trigger the use of various linux-specific code (e.g., posix >> sockets). > > If it's a decent configure script, passing --host=i686-w64-mingw32 or > --host=x86_64-w64-mingw32 should work just fine. If there's a configure > script present, try using that. It cannot be used to get a mingw32-make > compatible makefile. Please let me respond both to Ruben's and earlier comments: Initially I would like to just get QuickFIX built and play around with it. I may or may not end up having a long-term interest in it. So for the time being I do not think that I would want to invest the effort into adding mingw support to the autotools build process (unless it were already almost there). Also, it probably wouldn't make much sense in adding formal mingw support to QuickFIX unless the QuickFIX project were interested in upstreaming the changes. Based on the relative lack of response to my inquiry on the QuickFIX list and the fact that I've only seen a small handful of questions over the past five years about whether QuickFIX can be built with mingw, I'm guessing that there would be little interest in the QuickFIX community for supporting mingw. To respond to Ruben's and Eli's comments: 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. 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. 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.) >> ... >> 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 so. >> >> Thanks for any advice. >> >> K. Frank Thanks to All for your comments. I'll report back if I learn anything useful. K. Frank |
From: JonY <jo...@us...> - 2013-01-06 01:21:08
Attachments:
signature.asc
|
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. |
From: Ruben V. B. <van...@gm...> - 2013-01-06 09:49:15
|
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 > > > > ------------------------------------------------------------------------------ > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: Kai T. <kti...@go...> - 2013-01-06 10:54:29
|
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 |
From: Ruben V. B. <van...@gm...> - 2013-01-06 11:17:09
|
2013/1/6 Kai Tietz <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. > That was kind of my point :) Thanks for exemplifying it a bit more (my communication sometimes lacks in clarity) Ruben > > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: JonY <jo...@us...> - 2013-01-06 11:37:58
Attachments:
signature.asc
|
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 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 Like Kai says, autotools does not imply any API requirement on the host, the same can be said of cmake, jam or whatever. Unfortunately, autotools IS the golden standard to compare against, it has the capability to: 1. Detect compiler capabilities. 2. Detect C-library API capabilities. 3. Detect installed headers and libraries. 4. User configure arguments to modify build behavior. 5. Add custom search paths easily. 6. Modify compiler flags easily. 7. Allow user to specify a compiler other than gcc or whatever platform default. 8. Abstract way to generate shared libraries. 9. Stage and install compiled binaries. 10. Support cross compiles by simply specifying the triplet. All this without the need for the user to modify any files at all. I am even using it to drive MSVC. No funny files to edit, no editing obscure settings, no custom environment variables. I am annoyed that most other build system simply assume platform attributes without testing them. You end up with stupid things like outdated assumptions, "Windows does not have ipv6 support at all, absolutely none at all, even if it was released with compatible API and supported several years ago". I am also sure you have come to libraries that insist that you build on Windows for Windows with no way to compile from cross from Linux. It might not be the fastest, but it is the most feature complete, portable and flexible build system in common use. |
From: Ruben V. B. <van...@gm...> - 2013-01-06 12:55:53
|
2013/1/6 JonY <jo...@us...> > 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 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 > > Like Kai says, autotools does not imply any API requirement on the host, > the same can be said of cmake, jam or whatever. Unfortunately, autotools > IS the golden standard to compare against, it has the capability to: > > 1. Detect compiler capabilities. > 2. Detect C-library API capabilities. > 3. Detect installed headers and libraries. > 4. User configure arguments to modify build behavior. > 5. Add custom search paths easily. > 6. Modify compiler flags easily. > 7. Allow user to specify a compiler other than gcc or whatever platform > default. > 8. Abstract way to generate shared libraries. > 9. Stage and install compiled binaries. > 10. Support cross compiles by simply specifying the triplet. > > All this without the need for the user to modify any files at all. I am > even using it to drive MSVC. No funny files to edit, no editing obscure > settings, no custom environment variables. > > I am annoyed that most other build system simply assume platform > attributes without testing them. You end up with stupid things like > outdated assumptions, "Windows does not have ipv6 support at all, > absolutely none at all, even if it was released with compatible API and > supported several years ago". I am also sure you have come to libraries > that insist that you build on Windows for Windows with no way to compile > from cross from Linux. > 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-mingw32-g++ -DHAVE_CONFIG_H -I. -I/m/Development/Source/quickfix/src/C++/test -I../../.. -I.. -I../../../UnitTest++/src -g -O2 -Wall -ansi -Wpointer-arith -Wwrite-strings -I/libxml/include/libxml2 -O0 -g -MT DictionaryTestCase.lo -MD -MP -MF .deps/DictionaryTestCase.Tpo -c DictionaryTestCase.cpp -DDLL_EXPORT -DPIC -o .libs/DictionaryTestCase.o In file included from ../Exceptions.h:27:0, from ../Dictionary.h:31, from DictionaryTestCase.cpp:28: ../Utility.h:71:24: fatal error: sys/socket.h: No such file or directory #include <sys/socket.h> ^ compilation terminated. To Frank: I suggest writing some kind of build script or file from the VC project files, which have a high chance of having all the Windows stuff set right. Remember to drop stdafx.h and mind specific defines and such that would signify the exclusion of the Unix code. Hope this helps, Ruben > It might not be the fastest, but it is the most feature complete, > portable and flexible build system in common use. > > > > > > ------------------------------------------------------------------------------ > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > |
From: K. F. <kfr...@gm...> - 2013-01-06 14:15:33
|
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 been browsing the online documentation. I don't yet see a discussion of how to import / translate a visual-studio solution file. Could you point me to a section of the documentation that covers this (or maybe the right button to click on the CodeLite application)? (I've also recopied this post to the mingw-users list, because I think that was the list Peter was using.) On Sun, Jan 6, 2013 at 7:55 AM, Ruben Van Boxem <van...@gm...> wrote: > 2013/1/6 JonY <jo...@us...> >> >> 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 up with windows threading and winsock. >> >>>> (Just a hope.) >> >>> ... > > 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): For my education, what specific autotools command line did you type? Something like: ./configure --host=x86_64-w64-mingw32 && make ? Did you run it on linux or under msys? > > libtool: compile: x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I. > -I/m/Development/Source/quickfix/src/C++/test -I../../.. -I.. > -I../../../UnitTest++/src -g -O2 -Wall -ansi -Wpointer-arith -Wwrite-strings > -I/libxml/include/libxml2 -O0 -g -MT DictionaryTestCase.lo -MD -MP -MF > .deps/DictionaryTestCase.Tpo -c DictionaryTestCase.cpp -DDLL_EXPORT -DPIC > -o .libs/DictionaryTestCase.o > In file included from ../Exceptions.h:27:0, > from ../Dictionary.h:31, > from DictionaryTestCase.cpp:28: > ../Utility.h:71:24: fatal error: sys/socket.h: No such file or directory > #include <sys/socket.h> > ^ > compilation terminated. Is the output of the configure step a relatively straightforward makefile (i.e., not too many layers of variables or sub-makefiles)? If so, may I ask you to email me a copy? Because the linux and windows source distributions are the same (at least as far as I can tell), I think if I have a plain-vanilla makefile, I'll be able to tweak the #ifdef's in the source or maybe the predefined preprocessor macros passed in to the compiler, and get things to work. The code isn't that bad. The only unix / windows differences that I've come across are sockets, threads, and the stdafx.h stuff, so I think I should be able to sort things out. > To Frank: I suggest writing some kind of build script or file from the VC > project files, which have a high chance of having all the Windows stuff set > right. Remember to drop stdafx.h and mind specific defines and such that > would signify the exclusion of the Unix code. Yes, that is my current plan of action, trying to leverage the CodeLite solution-file translation that Peter mentioned. > Hope this helps, Very much so. > Ruben > ... Thanks for everyone's help. K. Frank |
From: K. F. <kfr...@gm...> - 2013-01-06 18:03:24
|
Hi Sergio! Thanks for your reply and the very interesting data point that you've got this working. I am taking the liberty of copying this to the QuickFIX, mingw, and mingw64 lists. On Sun, Jan 6, 2013 at 11:33 AM, Info <in...@ma...> wrote: > > Ciao Frank. > > Any update/news on this issue? I'm a MinGW user and no problem building > it. I'm plodding ahead, and I think I understand the basic issues, but I haven't built QuickFIX yet. Do I understand your comment correctly that you have built QuickFIX with mingw? If so, could you let me know how you did it? I'm not looking for a detailed step-by-step recipe (at least not initially), but your basic approach. Did you set up a makefile by hand? Did you run autotools under msys and it worked out of the box? Did you cross-compile on linux? Etc., etc.? Thanks for any pointers on the best way to proceed. > Cheers. > > Sergio. And a hearty "Ciao Sergio" to you! K. Frank > -------- Original Message -------- > Subject: Re: [Mingw-users] [Mingw-w64-public] Thoughts on how to build a > linux / visual studio project (QuickFIX) with mingw > Date: Sun, 6 Jan 2013 09:15:26 -0500 > From: K. Frank <kfr...@gm...> > Reply-To: MinGW Users List <min...@li...> > To: min...@li... > CC: MinGW Users List <min...@li...> > > Hi Ruben (and Peter) - > > First, thanks to everyone for their comments. This discussion has > been very informative and helpful. > ... |
From: K. F. <kfr...@gm...> - 2013-01-06 19:37:33
|
Hello Sergio! On Sun, Jan 6, 2013 at 2:04 PM, Info <in...@ma...> wrote: >> I am taking the liberty of copying this to the QuickFIX, mingw, >> and mingw64 lists. > > No worries. I hope they're interested! > >> Do I understand your comment correctly that you have built QuickFIX with >> mingw? > > QuickFIX builds fine under MinGW! Excellent! Now if I can only learn how to do it. >> If so, could you let me know how you did it? > > The same way as you would build any other app: configure --prefix=/mingw > ..... then: make then: make install I have a couple of questions about this: According to Ruben's post in a sister thread on the mingw-w64-public list: http://sourceforge.net/mailarchive/message.php?msg_id=30313744 it seems that the configure / make approach doesn't work out of the box. Also, looking at the source code it seems that it won't / can't work (see various comments in the thread), at least not without modifying the source. What, specifically did you do to get it to work? Obviously, if I type "configure" in a plain-vanilla windows command prompt, nothing will happen, because windows doesn't have a configure command and doesn't recognize unix shell scripts. So, did you cross-compile under linux? Did you run configure under msys? Something else? When you built QuickFIX under mingw, from where did you get the source? I got my source directly from www.quickfixengine.org, see: http://www.quickfixengine.org/download Did you have to modify the source at all to get it to compile with mingw? > Can you advise a 'proper' way of testing it once we have the binaries? "Once we have the binaries?" I thought you already had the binaries, because you've built QuickFIX with mingw. Or did you mean something else? As for testing, the source distribution I downloaded (see above) comes with both c++ unit tests that I suppose are build targets in the unix-style makefile and/or the visual-studio solution file. There are also ruby-driven (so for this piece there is a ruby dependency, and you have to install ruby) acceptance tests. So my speculation is that one proceeds as follows: 1) build QuickFIX -- no error? good. 2) run unit tests -- tests pass? better. 3) run acceptance tests -- test pass? best! To me it seems sensible that the proper way of testing is to run the test suites that come with the distribution. > Cheers. > > Sergio. Thanks for following up;. K. Frank |
From: JonY <jo...@us...> - 2013-01-06 13:34:20
Attachments:
signature.asc
|
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-mingw32-g++ -DHAVE_CONFIG_H -I. > -I/m/Development/Source/quickfix/src/C++/test -I../../.. -I.. > -I../../../UnitTest++/src -g -O2 -Wall -ansi -Wpointer-arith > -Wwrite-strings -I/libxml/include/libxml2 -O0 -g -MT DictionaryTestCase.lo > -MD -MP -MF .deps/DictionaryTestCase.Tpo -c DictionaryTestCase.cpp > -DDLL_EXPORT -DPIC -o .libs/DictionaryTestCase.o > In file included from ../Exceptions.h:27:0, > from ../Dictionary.h:31, > from DictionaryTestCase.cpp:28: > ../Utility.h:71:24: fatal error: sys/socket.h: No such file or directory > #include <sys/socket.h> > ^ > compilation terminated. > Ugh, do I have to repeat myself? Autotools does not imply any API usage. You are blaming the errors in the code on the buildsystem. You even got pass configure. > To Frank: I suggest writing some kind of build script or file from the VC > project files, which have a high chance of having all the Windows stuff set > right. Remember to drop stdafx.h and mind specific defines and such that > would signify the exclusion of the Unix code. > Yes, you can do this by excluding Unix specific code from Makefile.am via AM_CONDITIONAL, defines with AC_DEFINE in configure.ac, keeping all of it in a single build system if you prefer. The error Ruben sees looks like it was from a test case that was designed to run from Unix, it should be fine to exclude it. |
From: Ruben V. B. <van...@gm...> - 2013-01-06 13:38:36
|
2013/1/6 JonY <jo...@us...> > 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-mingw32-g++ -DHAVE_CONFIG_H -I. > > -I/m/Development/Source/quickfix/src/C++/test -I../../.. -I.. > > -I../../../UnitTest++/src -g -O2 -Wall -ansi -Wpointer-arith > > -Wwrite-strings -I/libxml/include/libxml2 -O0 -g -MT > DictionaryTestCase.lo > > -MD -MP -MF .deps/DictionaryTestCase.Tpo -c DictionaryTestCase.cpp > > -DDLL_EXPORT -DPIC -o .libs/DictionaryTestCase.o > > In file included from ../Exceptions.h:27:0, > > from ../Dictionary.h:31, > > from DictionaryTestCase.cpp:28: > > ../Utility.h:71:24: fatal error: sys/socket.h: No such file or directory > > #include <sys/socket.h> > > ^ > > compilation terminated. > > > > Ugh, do I have to repeat myself? Autotools does not imply any API usage. > You are blaming the errors in the code on the buildsystem. You even got > pass configure. > 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's thoughts when written will not work. And because autotools is very Unix-centric, chances are a lot higher that they were written for Unix, and not with Windows in mind. This is a practical/statistical fact, not some disadvantage of autotools. But whatever, I don't care anymore. You seem intent to not listen. Ruben > > To Frank: I suggest writing some kind of build script or file from the VC > > project files, which have a high chance of having all the Windows stuff > set > > right. Remember to drop stdafx.h and mind specific defines and such that > > would signify the exclusion of the Unix code. > > > > Yes, you can do this by excluding Unix specific code from Makefile.am > via AM_CONDITIONAL, defines with AC_DEFINE in configure.ac, keeping all > of it in a single build system if you prefer. > > The error Ruben sees looks like it was from a test case that was > designed to run from Unix, it should be fine to exclude it. > > > > > > ------------------------------------------------------------------------------ > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > |
From: JonY <jo...@us...> - 2013-01-06 14:49:05
Attachments:
signature.asc
|
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's thoughts when written will not work. > And because autotools is very Unix-centric, chances are a lot higher that > they were written for Unix, and not with Windows in mind. This is a > practical/statistical fact, not some disadvantage of autotools. The statistics still do not mean autotools make Unix API a requirement, does it? The author already said it was working with MSVC, at which it was suggested he added mingw support to the configure scripts to follow the MSVC project if he wanted flexibility rather than adding yet another build system. |
From: Ray D. <min...@gm...> - 2013-01-06 16:35:25
|
I've had a quick look at the source code and it's littered with stuff like: #ifdef _MSC_VER #include <Winsock2.h> ... 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 ) ...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. 2. Hand writing a Makefile is a lot of one-off-work for any single project. 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). 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. 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 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 Finally, I recommend console2 for any MSYS work. It's really good. http://sourceforge.net/projects/console/ Good luck, Ray. On Sun, Jan 6, 2013 at 2:48 PM, JonY <jo...@us...> wrote: > 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's thoughts when written will not work. >> And because autotools is very Unix-centric, chances are a lot higher that >> they were written for Unix, and not with Windows in mind. This is a >> practical/statistical fact, not some disadvantage of autotools. > > The statistics still do not mean autotools make Unix API a requirement, > does it? > > The author already said it was working with MSVC, at which it was > suggested he added mingw support to the configure scripts to follow the > MSVC project if he wanted flexibility rather than adding yet another > build system. > > > > ------------------------------------------------------------------------------ > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: NightStrike <nig...@gm...> - 2013-01-06 17:31:46
|
On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly <min...@gm...> 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 <Winsock2.h> > ... > > So the fact is that the code itself conflates Windows builds with the > MSVC compiler via _MSC_VER You know, I bet that if someone cleaned up the distinction between windows-specific ifdefs and MSVC specific ifdefs, you could probably just specify gcc.exe in the VS IDE instead of cl.exe. Since somebody on the QuickFix project already maintains the project files, no additional work is needed. |
From: K. F. <kfr...@gm...> - 2013-01-06 17:42:22
|
Hello Ray! On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly <min...@gm...> 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 |
From: Earnie B. <ea...@us...> - 2013-01-06 16:41:30
|
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 <Winsock2.h> > ... > > 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 ) > This is the correct MACRO to use for compiler specific things like this. So to get this to build correctly with GCC you'll need to determine which items in the code identified by _MSC_VER should really be _WIN32 and change them. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Ray D. <min...@gm...> - 2013-01-06 17:03:38
|
Yes, That's precisely what I meant by the word "conflates". On Sun, Jan 6, 2013 at 4:41 PM, Earnie Boyd <ea...@us...> 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 to detect Windows build. It is the right > MACRO to detect using MSVC. > >> #include <Winsock2.h> >> ... >> >> 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 ) >> > > This is the correct MACRO to use for compiler specific things like this. > > So to get this to build correctly with GCC you'll need to determine > which items in the code identified by _MSC_VER should really be _WIN32 > and change them. > > -- > Earnie > -- https://sites.google.com/site/earnieboyd > > ------------------------------------------------------------------------------ > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public |