[vtkusers] Re: [CMake] Re: Compiling VTK-5.0.2 with Cygwin make

[Mike Jackson]

Just to jump in here. On OS X I also noticed that X11 libs are linked into
VTK 502 even though I am compiling with Carbon.. Is that correct? Doesn't
seem so.

Mike Jackson


On 10/20/06 3:20 PM, "Patrick D. Emond" <patrickdemond at gmail.com> wrote:

> For those people who, like me, are primarily interested in getting VTK5
> built under cygwin the simplest solution seems to be to make sure that
> your cygwin install has no X11 libraries installed.  I completely
> reinstalled cygwin making sure to not include any X11 packages and the
> VTK install went off without a hitch (no need to change the
> CMakeCache.txt file after running CMake).
> 
> Hope that helps someone.
> 
> - Patrick
> 
> 
> Steve Robbins wrote:
>> Hello all,
>> 
>> This thread begins at
>> http://public.kitware.com/pipermail/vtkusers/2006-September/087106.html
>> 
>> 
>> Quoting Steve Robbins <smr at sumost.ca>:
>> 
>>> I'm having the same problem as Patrick D. Emond
>>> [http://public.kitware.com/pipermail/vtkusers/2006-September/086953.html]
>>> in
>>> building VTK under cygwin.
>> 
>> To recap: I am building VTK 5 sources on cygwin under windows XP.  The
>> initial
>> build failed with link errors.  Cygwin provides two different OpenGL
>> implementations: one that runs on top of X11 and one that doesn't.  The
>> cause of
>> the link errors is that the compilation used gl.h from X11 but linked
>> against
>> the non-X11 GL library.
>> 
>> I configured with VTK_USE_X set to OFF.  However, CMake saw fit to add
>> -I/usr/X11R6/include to the compile command line and therefore brought
>> in the
>> wrong gl.h.
>> 
>> In a series of emails with helpful folks like David Cole and Brad King I
>> learned the following:
>> 
>> 0. A workaround exists: after configuring, edit CMakeCache.txt to set
>> the OPENGL_* variables correctly, reconfigure, and build.
>> 
>> 1. The only way to debug CMake's actions is to sprinkle MESSAGE()
>> throughout
>> its input files, including those in /usr/share/cmake-2.4.3.
>> 
>> 2. The symbol WIN32 *is* defined on cygwin, contrary to my initial
>> speculation.
>> 
>> 3. The file /usr/share/cmake-2.4.3/Modules/FindOpenGL.cmake has the
>> following
>> code:
>> 
>> IF (WIN32)
>>   IF (CYGWIN)
>> 
>>     FIND_PATH(OPENGL_INCLUDE_DIR GL/gl.h
>>       /usr/include
>>       /usr/include/w32api
>>       /usr/X11R6/include
>>     )
>> 
>> Despite the existence of /usr/include/w32api/GL/gl.h, the variable
>> OPENGL_INCLUDE_DIR is set to /usr/X11R6/include by this code.  This is
>> *not* an effect of CMake caching, nor have I defined the environment
>> variable INCLUDE.
>> 
>> What is happening is that FIND_PATH() searches an internal, hard-coded set
>> of paths *before* the paths specified in the arguments.  This set of
>> paths happens to include /usr/X11R6/include, so if that directory contains
>> GL/gl.h, there's no way /usr/include/w32api/GL/gl.h (the correct, non-X11
>> header) will be found.
>> 
>> At this point, deep in a private email thread, the speculation became
>> that the internal set of include paths was in the wrong order.  In fact,
>> however, there is no possible correct ordering if one wants to support
>> building with both versions of OpenGL, based on a build-time configuration
>> variable (VTK_USE_X).  Rather, I think, the code in FindOpenGL.cmake should
>> resemble the following:
>> 
>> IF(VTK_USE_X)
>>   FIND_PATH( OPENGL_INCLUDE_DIR GL/gl.h /usr/X11R6/include
>> NO_DEFAULT_PATH )
>> ELSE
>>   FIND_PATH( OPENGL_INCLUDE_DIR GL/gl.h /usr/include/w32api
>> NO_DEFAULT_PATH )
>> ENDIF
>> 
>> The trouble is, of course, that FindOpenGL.cmake has no knowledge of
>> "VTK_USE_X".
>> 
>> It's clear that there's a bug: building on cygwin should work
>> out-of-the-box
>> for both settings of VTK_USE_X.  It's less clear (to me) whether the bug
>> should
>> be fixed in VTK or in CMake.
>> 
>> -Steve
>>