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 (FindFLTK.cmake). The code in there is hopelessly
broken. It tries to detect FLTKConfig.cmake to ascertain whether FLTK
was built with CMake or not. Well, FLTKConfig.cmake no longer exists in
the FLTK source tree, so this detection fails. Then, FindFLTK.cmake
tries to find fluid under ${FLTK_INCLUDE_DIR}/fluid -- this only works
if FLTK was built with autotools using an in-tree build.
In short, there is no way, given the current tools, that FLTK can be
properly detected in the TigerVNC build unless:
(a) it was built with autotools using an in-tree build, and
FLTK_INCLUDE_DIR and FLTK_LIBRARY are overridden to specify the location
of the build directory and the library underneath it.
(b) the library is installed in a standard system location, such as
/usr/include and /usr/lib.
There is no way, period, that FLTK can be properly detected on Windows
using Visual C++. There is no way, period, that FLTK can be properly
detected on Unix if it is installed under a prefix other than the
standard /usr, /usr/local, etc.
<sigh>
This seems really hopelessly complicated, and at the moment, I don't
know how to tame it without bringing the FLTK code into our tree. That
seems like a marginally more sane approach than writing our own version
of FindFLTK.cmake.
The only way I am willing to accept the requirement of developers
building their own version of FLTK is if it can be built using basically
the same recipes as TigerVNC-- that is, using CMake. The process
becomes very unwieldy and unsupportable if very specific procedures are
required to build FLTK for each platform, and if those procedures differ
from those used to build TigerVNC, and if not using those procedures
causes FLTK detection to fail when building TigerVNC.
Note that the detection failure isn't always nice, either. In certain
cases on OS X, CMake will simply abort with TRACE/BPT TRAP and won't
tell you why it's aborting, and there is nothing in the log to indicate
that it is tripping up on detecting FLTK.
I'm a lot more knowledgeable about this stuff than we can expect the
average person trying to use the TigerVNC code to be. I really think
that the only sane way forward is an in-tree version, for now. We can
revisit the issue later. I see indications that there is a planned
overhaul of FindFLTK.cmake at some point in the future.
On 6/22/11 2:46 AM, DRC wrote:
> 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 people don't want to use the in-tree version, they don't have to, but
> trying to document a reproducible build procedure is pretty much
> impossible for Windows right now, because building FLTK requires the
> Visual Studio IDE. This precludes being able to build a 64-bit version
> unless you are using the "paid" version of Visual C++, and it's not
> straightforward even then. It's also really a pain to build FLTK on
> Unix. FLTK isn't using a modern version of autotools, so out-of-tree
> builds and other stuff doesn't work.
>
> I am generally OK with introducing external dependencies that are
> readily available in binary library form on all supported platforms (as
> is the case for libjpeg-turbo), but FLTK isn't even generally available
> on Linux. I am not in favor of hard external dependencies that have to
> be built from source, particularly when the build procedure for those
> dependencies is not straightforward and we're requiring custom patches
> at the moment.
>
> With GnuTLS, having a somewhat esoteric build procedure is OK, because
> that is not a critical component for TigerVNC. FLTK is. It needs to be
> easier to build.
>
> I've been including FLTK in the VirtualGL source for years, with no
> issues. It's not security-critical code, so we don't really need to
> focus on "maintaining" it in our tree. We would just need to upgrade it
> if something didn't work.
>
> DRC
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
