On Thu, 2 Apr 2009, DRC wrote:
If you use MSYS, Cygwin is not necessary. So I think it's safe to say installing MSYS, MinGW and even NASM on Windows should be as easy or even more easy than installing MSVC 2008.Well, except that MSYS doesn't have the AutoTools. So if you insist on using AutoTools, then that requires Cygwin, which is a somewhat bloated install.
With AutoTools, you mean "autoreconf" and the tools to recreate the configure script etc from configure.ac etc? That's probably true, but few people needs that: They just need to run ./configure and build everything with "make". This should all be possible with just MSYS, without Cygwin.
And if you think MSVC technology changes quickly, Cygwin pushes out incompatible package changes on practically a daily basis.
Probably true, I don't like Cygwin very much.
MinGW simply does not support the full Win32 spec, and the parts of the spec it does support often do not behave correctly.
Our experience is that the things that are supported behaves correctly. In the cases when you need to use an API that's not yet supported, it's often fairly easy to create the stub library that's missing.
We have had some problems building COM applications, though. I'm still unsure of well COM is actually supported by MinGW nowadays. We need to investigate this when we are fixing WinVNC so that it can be built with MinGW.
Don't think I haven't tried to use MinGW with VirtualGL and TurboVNC on many occasions. In the case of TurboVNC, it was a non-starter, because the TightVNC server code relied on some libraries that simply weren't provided by MinGW.
If it's just libraries, it's often very easy to add those.
Also, this goes back to the argument of maintainability. The goal isn't just to be able to compile our code once on a given platform. It has to be easy to add features and fixes to it. Maybe someone wants to use DirectX or some other technology that doesn't work with MinGW.
A quick Google points at http://mingw-starter.blogspot.com/2008/02/mingw-directx.html. Seems like DirectX and MinGW works fine.
went without a maintainer for years. Whether or not we're depending on a healthy OSS project or a healthy company, we're depending on something either way, and in either case, the rug could be pulled out from underneath us.
I agree, but one main difference is that with Open Source toolchains, the developers/"provider" can't suddenly forbid distribution and use, like Microsoft can.
MinGW is also gaining much momentum now, with the inclusion in Fedora and everything.
Microsoft could just as easily change the O/S and make it suddenly incompatible with MinGW, but seeing as how MSVC is their application, it's guaranteed that it will always work with their O/S.
Well, if they change the OS, then old applications won't run any longer. To some extent, this is what they are doing now with Vista and Windows 7, but Open Source projects as MinGW can adapt as well. The situation is not much different from projects such as Samba, and they seems to be doing quite well.
I again go back to looking to the OSS community for a best practices model, and if you look at the most popular Win32 OSS projects, the lion's share of them build with MSVC. That's because any serious professional Win32 developer has MSVC. It's just a fact of life.
I believe that if you instead look at Cross Platform OSS projects, the image will be different. Nowadays many applications are built with MinGW, including the popular VLC. I believe this includes the 64 bit version as well.
Best regards, ---
Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
