On 6/27/11 3:04 AM, Adam Tkac wrote:
> 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
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
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
Crisis may have been at least temporarily averted. Figured out how to
fake out FindFLTK.cmake. Still not very pretty, but it at least is
documentable.
Will keep everyone posted.
On 6/23/11 2:41 AM, DRC wrote:
> To keep everyone in the loop on this, I did discover after sending the
> previous m
To keep everyone in the loop on this, I did discover after sending the
previous message that FLTK can be built with CMake, but this uncovered a
variety of problems in our FLTK extensions patch. I've since fixed
those, but then I ran into another very weird problem in CMake's FLTK
detection module
After messing with trying to build FLTK on Windows, I really want to
include a "golden" version of the FLTK source in our tree and have the
library optionally built using the CMake build system (using a
USE_INCLUDED_FLTK option.) I'm more than happy to write this code and
do the integration.
If p
