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 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
