On Mon, 17 May 2010, DRC wrote:
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.
Developing on Windows on a daily basis would make me scream, regardless of
whether I'm using MinGW or another compiler :-)
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.
Yes, but it's quite easy to add missing libraries and headers, when
necessary.
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.
Adding support for a second build environment (such as MS VC) is one
thing. Starting to *require* that environment to be able to build
TigerVNC binaries with full functionality is an entirely different thing,
which I really don't like. That would mean that we - the core developers -
would not be able to build binaries on Linux. That would be a major
drawback.
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.
Well, you don't have to "rebuild" MinGW to get support for new APIs; you
just have to add the corresponding libraries and headers. But otherwise, I
agree with you that it's important to get new developers.
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.
It depends on which version of Visual Studio you are using. When we used
an older version ("Visual C++ .net Standard"), we got a lof of problems
with "internal compiler errors". I searched a lot for a solution on the
net, and eventually found a post from a Microsoft Developer that said that
building from a network share was not officially supported. It might work
in some cases though.
Now, almost a decade later, much have changed. But: A quick Google on
"visual studio network drive" indicates that this is still problematic.
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.
Yes, autotools is likely the main problem.
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
