Xmingwin For Cross Generation Applications
An anonymous reader writes "Xmingwin makes it practical to generate Windows programs from a Linux server. This column gives a recipe for setting up Xmingwin, outlines the most important reasons for doing so and shows you how to generate executables for multiple platforms -- including Windows DLLs -- from a single Linux source."
Winner of Company Most likely to produce Buggy Software....
The people who do this. You can produce work on the Server but to properly test you still need the windows environment. So you have to deploy to that, given that you need a testing environment per developer as well as for UAT and QA then your costs aren't really reduced. The advantages in terms of compile speed are killed in terms of transfer and deployment.
Somebody somewhere clearly things they need this, somebody somewhere doesn't work in large teams and on commercial apps.
Sorry to dis someones work, but I'd be more interested in a decent Open Source windows IDE on windows than being able to do a fraction of the work on Linux... and I loathe MS-Windows. Why do so many Open Source projects have to ape MS rather than take on the beast.
Too many people, too many projects. Come and save us IBM.
An Eye for an Eye will make the whole world blind - Gandhi
In my experience this is not what should be done.
Moving files like this, executables which are virii prone into one system or another helps with the spread of virii. Why? It may not look logical at first
What happens is systems that are not running the software can check it for the virii that do run on it. They'll miss the infections coming from the other platform, or perhaps some other one again.
What you end up with is a security risk. It pulls everything down the tubes.
- lets see, we have
...
- The mingw-runtime package
- The gcc-mingw32 package
How exactly is this different? We've been able to produce win32 executables using mingw and gcc for years now.Lots of people are posting on how this is potentially a bad idea. Sure, it's not likely to be as mature as other compiler environments. There's all kinds of small shops where this could simplify build infrastructure, though. Maintaining different build servers for all the platform variation a company chooses to support can be costly to build, especially with the infrastructure to do revision control and fire off simultaneous builds and package things together. If a company just needs to produce command line tools or simple DLL's to accelerate code in a scripting language, this might be a good choice.
Probably the largest win is allowing developers to unit test application logic on their local Windows desktop, if they prefer that environment, before doing final unit test, integration test, and deployment on top of *nix/Linux.
Like a lot of people here, I don't get it the point. Cross compilers are for developing for platforms that can't host development tools. When I did cross platform (Windows, Solaris, HP-UX) development, my tools were Vim and CVS plus the native compiler. Which platform would I edit on? Whichever was most convenient that moment.
On the other hand, for those who want to use MinGW for Windows development, check out the GPL Visual-MinGW. Al Stevens had some very nice things to say about it in the December 2002 issue of Dr. Dobb's. (The article isn't online, but the issue's table of contents is here.)
There are some significant licensing differences between MinGW and Cygwin. The Cygwin runtime is GPL (not LGPL!), but can be licensed for non-open use. The MinGW runtime is public domain.
Stupid job ads, weird spam, occasional insight at