On 10/6/11 2:50 AM, Peter Åstrand wrote:Remind me, which functionality is missing if you build without Visual Studio?WinVNC. It's always been WinVNC.
Yes, but what is the problem with WinVNC? Nevermind, I looked back at the discussions myself. It's the problem with IActiveDesktop missing from the MinGW distro.
IMHO, this is not unsolvable. If MinGW still refuses to add support for this, we should be able to include the missing definitions in the TigerVNC code base.
This is about to become even more of a problem, because I'm being contracted by another company to improve WinVNC so that it can be used on Vista and W7, and that may yet require the use of more APIs that aren't supported in MinGW. It has nothing to do with streamlining. It has to do with the fact that MinGW will always be playing "catch up" with Microsoft, and some of the Microsoft API's can't be included because of IP concerns. Thus, there will always be certain functionality that can't be leveraged through the MinGW toolchain. It
It can, it's just a matter of fixing a few missing stubs. It's not that difficult, and it's a better investment of time than the never-ending maintenance of having two toolchains.
The basic facts of this case are the same as they were 2 years ago: we cannot abandon Visual Studio without abandoning WinVNC,
We can.
Besides, let's back up a minute-- the modification that broke the Visual Studio build was in FLTK. The FLTK Project supports Visual Studio as one of their build chains, so someone was going to have to fix the build eventually in order for it to be accepted upstream. I assume that upstream acceptance is the ultimate goal for these FLTK patches.
Correct.
Thus, I believe that it is quite reasonable to expect that whoever is developing the FLTK patches test them on the compilers that the FLTK Project supports.
You can never test everything. You need to prioritize. From a TigerVNC perspective, if we could get rid of Visual Studio, we would no longer have to test every commit with that toolchain. That would be big win. When it comes to FLTK patches, we only need to do the minimum amount of work to get the patches accepted upstream. If we are lucky, others will fix up problems later.
FLTK actually supports many toolchains, both MinGW- and Cygwin, both VS 2008 and VS 2010 etc. I doubt that a typical patch contributor tests all combinations.
In any case, the FLTK patches are small compared to the entire TigerVNC code base. So in any case, it would be a big win if we do not need to test with two toolchains.
Every minute you guys spend arguing with me is a minute less that I have to spend on optimizing the VNC Viewer or doing other things that are supposed to be a priority, so I'll let you decide whether it's worth it to continue this discussion.
Having to "always check the build with MSVC prior to committing", ie test build with two different toolchains, will also require a lot of time, forever. We do not believe that this is an efficient way of working.
Here's an offer: If we fix so that WinVNC can be built with a standard MinGW distribution, can we then remove support for Visual Studio?
Rgds, ---
Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
