On 06/24/2011 06:24 AM, DRC wrote: > More fuel for this fire. When doing a Visual C++ build, we have to jump > through some hoops to prevent TigerVNC from depending on the Visual C++ > run-time DLL. FLTK doesn't jump through the same hoops. Thus, in order > to build a Visual C++ version of FLTK that works properly with TigerVNC, > I had to patch their CMakeLists.txt file. I seem to have managed to > tame the beast for now using a 128k patch against FLTK 1.3.0, but I > suspect that's going to become a support nightmare if we move beyond > 1.3.0 at some point. I don't think we're ever going to get the upstream > FLTK project to adopt all of our unique changes-- particularly not the > changes to their build system, which only apply to our project. > > It seems to me that, since FLTK is basically unusable in upstream form, > we're already maintaining a custom version, and we might as well > maintain it in our own tree where it's easier for people to build. Hello,
although I'm generally against inclusion of other sources in our code, you know portability issues best. If the patch against fltk will be so big, we can include fltk in our svn repo. It will make building of TigerVNC easier and changes in fltk upstream can be pulled into our tree. Regards, Adam ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
