On 10/4/11 2:26 AM, Peter Åstrand wrote: > Can you submit them to: > > http://www.fltk.org/site/str.php?U+P0+S-2+C0+I0+E0+Q
Probably better for Pierre or someone else who's familiar with that community's submission procedures to submit them, particularly since the patches are only relevant in the context of other patches. >> and (b) always check the build with MSVC prior to committing >> modifications to any libraries that affect that build. > > Unfortunately, we have no easy way of building with MSVC. To be honest, > we are avoiding it like the plague :-) > > I guess this situation where the MSVC build will occasionally go broken > is the price we have to pay for supporting two toolchains. I don't buy it. It is quite easy to set up a virtual Windows machine using VirtualBox and install the free Visual Studio compilers. All you would have to buy is a Windows license. I regularly build and test multiple platforms using the same source tree. Currently, this includes OS X, Windows/MSVC, Windows/MinGW, Linux/legacy, Linux/RHEL 6 (32-bit and 64-bit on all of the above), and Linux cross-compiling Windows. I do this using only a Mac and a Linux machine and virtualization. There is no reason why you should avoid MSVC like the plague. MSVC is the preferred mechanism for building software, both OSS and otherwise, on Windows platforms. It is necessary to use when building the TigerVNC Server for Windows. It is the means by which most developers will build our Windows code. Frankly, the fact that the main project developers insist on the use of esoteric build environments is a problem. If we're really expecting people to work with our code, then we need to be developing it in the same way we expect them to develop it. Throwing up our hands and saying that broken builds are the cost of doing business is not a very healthy attitude for an OSS project to have. You can look at it another way-- it costs Cendio more to pay me to fix those issues after the fact than it would cost you to fix them pro-actively-- not to mention the fact that it distracts me from the stuff that is supposed to be my focus (performance-related work.) From my point of view, it doesn't really matter as long as I'm getting paid, but in terms of the overall health of the project, I think it would be good to have more synchronization between the product and project development paradigms. Bear in mind that I spent 5 years of my life productizing a VNC flavor for a Fortune 500 company. I'm trying to steer TigerVNC away from the same pitfalls we encountered, but so far, I'm not having much luck. My experience is that, without synchronization between the product and the project, there is no way for the product to effectively leverage the resources of the OSS community. If the beta cycles coincide between product and project, then any testing/stabilization that occurs with the project theoretically benefits the product as well, and vice versa. As it is, though, we're all in the dark regarding what Cendio is doing with the code. It would be helpful to at least have some communication regarding upcoming ThinLinc releases, so we know generally what snapshot of the code that Cendio is testing/stabilizing. ------------------------------------------------------------------------------ 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
