On 5/17/10 12:18 PM, Peter Åstrand wrote: >> 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...
To the above, I will respond that I really would like to see you try to get a production build environment for TigerVNC up and running on Windows using MinGW -- and use it on a daily basis -- before you dogmatically support using that build system on that platform. I like the idea of MinGW too, but the reality does not match up. It is, ironically, a great platform for cross-compiling Windows code on Linux but not a great platform for compiling Windows code on Windows. My previous e-mail went into great detail about what is required to get the build environment up and running, why I believe that this is too much to ask of most developers, as well as the severe performance problems with the build environment, so I won't repeat any of that here. >> 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. If something is crashing in one compiler and not in another, chances are that the code is doing something stupid, and we probably want to fix it. Yes, I agree that a dual build environment is non-ideal. But what's less ideal is not having a usable build environment on Windows at all. As far as code compatibility, let's start with the fact that MinGW is constantly behind the curve on the Windows API and always will be. Here's the problem as I see it-- you're more concerned about having a unified build environment, and that is a laudable goal, but not if it artificially constrains developers from being able to innovate. Witness how much trouble we're going through just to get a version of the compiler that implements CLSID_ActiveDesktop. So what if, for instance, someone discovers that they need to use a newer Windows API to make our viewer work on Windows 7? What if that API isn't in MinGW? We're either forced to dumb down our Windows code or patch our compilers. What I'm trying to do is get TigerVNC to the point where people outside the project are interested in actually working on our code. That means having a build environment that is easy to set up, performant, and doesn't constrain innovation. If a full rebuild takes forever, then no one is going to want to work on the TigerVNC Windows code (including me!) A developer can't be expected to stop what they're doing and patch/rebuild MinGW every time they want to use a new API routine. > The suggested approach was tried in the TightVNC project. It was a big > pain to work with: Every time I needed to build a Windows binary, I had to > play the fix-the-broken-windows-build game. And the MS development tools > doesn't play nice with cross platforms development: For example, at > least earlier, you couldn't build if the source was located on a > networked file server, you had to have all sources on a local disk such > as C: ... (!) That is completely false. I have been building all of my other open source projects with free versions of Visual Studio for 7 years now, and almost always from a networked file server. >> The other issue with MinGW is that it simply takes too long to build >> with it on a real Windows system. I personally cannot be productive as >> a TigerVNC developer if I have to wait for the build to grind for 20 >> minutes every time I change something significant. I mean, just >> re-running the configure script takes a good 5 minutes of that. It >> isn't workable. > > My experience of Visual Studio is the same. Every now and then, you have > to "Rebuild Everything", and it takes forever. Yes, well, imagine it taking 10 times longer than forever, and now you understand the problem with MinGW. It is literally an order of magnitude slower than Visual C++ when rebuilding a project the size of TigerVNC. I suspect that much of this is the fault of autotools, not the compiler itself. ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
