[vtkusers] MacOSX: fundamental Carbon/Tk/X11 problem

[Stephen R. Saucier]

Yves Starreveld <ystarrev at atamai.com> writes:

> No, they don't need X11.
> 
> In /Library/Frameworks/Tk.framework/Versions/8.4/Headers, there exists
> an X11 directory which contains:
> 
> X.h, Xatom.h, Xfuncproto.h, Xlib.h, Xutil.h, cursorfont.h, keysym.h,
> keysymdef.h, xbytes.h
> 
But this is just it; unless I misunderstand, these are X11 headers,
and they are included when you are compiling vtk with Tcl/Tk. This
doesn't make sense since the desire was to compile vtk to use Carbon,
and not X. If the build is including the X header files, then
somewhere in the source it thinks that it is still running under X and
therefore would explain a lot of the inconsistent behavior when
running vtk.

> When VTK builds with Tcl wrappers, it uses these files when you add
> /Library/Frameworks/Headers to the CMakeCache.txt file.
> 
> I use the following settings:
> 
> //What is the path where the file tcl.h can be found
> TCL_INCLUDE_PATH:PATH=/Library/Frameworks/Tcl.framework/Headers;/
> Library/Frameworks/Tcl.framework/PrivateHeaders
> 
> //Where can one of the tcl, tcl84, tcl8.4, tcl83, tcl8.3, tcl82,
> // tcl8.2, tcl80 or tcl8.0 libraries be found
> TCL_LIBRARY:FILEPATH=-framework Tcl
> 
> //What is the path where the file tk.h can be found
> TK_INCLUDE_PATH:PATH=/Library/Frameworks/Tk.framework/Headers;/Library/
> Frameworks/Tk.framework/PrivateHeaders
> 
> //Where can one of the tk, tk84, tk8.4, tk83, tk8.3, tk82, tk8.2,
> // tk80 or tk8.0 libraries be found
> TK_LIBRARY:FILEPATH=-framework Tk
> 

Could you explain to me why you included the PrivateHeaders directory?
I didn't include those directories and I didn't encounter any problems
while compiling. Since the TCL_INCLUDE_PATH and TK_INCLUDE_PATH are
only asking for one file each, I don't understand how it would make
sense to list two directories for it -- if tcl.h and tk.h are in both
the Headers and PrivateHeaders directories, it seems that listing both
would result in conflicts, and if not, then I don't see the purpose in
listing the extra directories.

If this solves some problems though, it seems that the *_LIBRARY_PATH
variables are improperly documented, and I would like to add this
information to my help page.

-Stephen Saucier