>> 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.
Quite easy? No, far from it. Witness how long it has taken to resolve
the CLSID_IActiveDesktop issue, and it appears to me that it still
hasn't been fully resolved (the interface has been added to the include
files but not the libraries yet.)
>> 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.
I understand that, which is why I'm not proposing we do it. What I'm
proposing is that we support building with MS Visual C++ Express Edition
(the free version of the compiler) 2005 or later as an alternative build
system for now. We can revisit this issue once binaries are available
of MinGW that have the necessary interfaces to cleanly build TigerVNC
and once MinGW has an appropriate installer on Windows.
>> 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.
Well, minimally we'd need to develop and maintain a procedure for
building these updated libraries, in addition to the procedure for
installing MinGW itself. I'm not saying it can't be done. I'm just
saying that it's difficult enough that most people won't bother.
>> 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.
Again, this is old information about an old compiler. We should not
support Visual C++ prior to 2005. All of the free editions work fine on
network shares. For that matter, I've also used Visual C++ 6.0
successfully on network shares for over a decade. I'm not sure how you
managed to get a version of Visual C++ that has so many bugs and doesn't
optimize code, etc. I have never had those problems with any version of
Visual C++, and I've been using it for nearly 15 years.
------------------------------------------------------------------------------
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
