On Mon, May 17, 2010 at 07:18:41PM +0200, Peter Åstrand wrote: > On Mon, 17 May 2010, DRC wrote: > > >>Windows developers would still be able to edit and browse the source > >>with Visual Studio, even if they need to build with MinGW. > > > >Per my previous message, there are a lot of additional components > >required, not just MinGW. We'd have to distribute the necessary MSYS > >components as well. > > MSYS is a part of the MinGW project; not a big problem. > > > >In total, this would amount to hundreds of megabytes of software, > >which someone from our group would have to maintain. > > We are not talking about taking over maintainership from the MinGW > folks; just provide the necessary fixes to make the build easier. > This can be in the form of documentation and/or updated packages. > Likely, we could perhaps also get help from the MinGW folks with > some problems. > > Size-wise, I don't think that a couple of hundreds of megs is much > nowadays. As a side note, the Nokia N900 / "Maemo SDK Virtual Image" > download is 1.6 GiB... > > > >Adam is 100% right that maintaining the VC++ build scripts is tons > >easier. > > But it's not just about maintaining build scripts: We need to > maintain *code* compatibility with two compilers. Bug reports would > need to include which of the two build systems were used. Some > crashes might only happen with one compiler, so developers might be > forced to have both build systems available to be able to replicate > problems.
I just tested the MS Visual C++ Express 2010 and I have to agree with you the "code compatibility" is a valid point. Visual C++ prints bunch of stupid warnings, like "hey, this function is not thread safe". Seems that non-threaded Windows program is simply a piece of crap... But Darrell is also right that setup of MinGW environment might be problematic. For example one comment on http://sourceforge.net/projects/mingw clearly says this: "You should make it easier to install this project. I had to download millions of files and figure out what to do with them. Please fix this." For people who have never heard about GNU build chain (gcc, autotools + binutils) it's hard to determine what they should download. And the stock MSYS contains too old releases of gcc, AFAIK. Also, when code is not compiled correctly with one compiler, it usually means that there is a problem in code, not in the particular compiler. I would like to propose this approach: 1. Mark (and keep) MinGW as our primary build environment on Windows. 2. Brush over Visual Studio files and port them to Visual C++ Express 2010. We can call this system as a secondary. I guess it's ~15 mins work. 3. Try to improve MinGW to stage at which we can say "Hey, Visual C++ doesn't have any advantage over MinGW so use MinGW". Especially the CLSID_ActiveDesktop problem is currently tricky on Windows and I don't think that unexperienced developer can build winvnc on Windows via MinGW. What is your opinion about it? Regards, Adam -- Adam Tkac, Red Hat, Inc. ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
