Building the RenderingTk Module on Windows

Support
1

Hi!

I am currently using the classes implemented in the RenderingTk module in a python project. I managed to build the wrapped vtkRenderingTk-X.X.so on Linux, but I am struggling to get it to work on Windows.

I followed this build order:

  • compile TCL/TK 9.00 according to How to Compile Tcl
  • configure VTK using cmake-gui
    • VTK_WRAP_PYTHON = ON
    • VTK_WHEEL_BUILD = ON
    • VTK_USE_TK = ON
    • TCL_INCLUDE_PATH, TCL_LIBRARY, TCL_TCLSH = path_to_tcl
    • TK_INCLUDE_PATH, TK_LIBRARY, TK_WHISH = path_to_tk
  • compile RenderingTk solution project with VS17

The problems arise with TK_INTERNAL_PATH. When compiling TK, no OS specific internal headers were created. If I simply point to the tk\generic\ folder, I receive X11 import errors. On Linux the internal headers are distributed through the dev packages. I Tried to compile tk with all and depend flags aswell.

Can someone point out where my mistake is?

Thanks a lot!

2

The latest version of Tcl/Tk that I’ve tried with VTK is Tcl/Tk 8.6, and I was successful on both Linux and Windows. That was a while ago (probably VTK 9.2?) but I can try again with VTK 9.4 later this week.

My suspicion is that Tcl/Tk 9.0 won’t work.

3

I just finished a successful test build with VS17 on Windows 10,

  • VTK 9.4.0
  • Python 3.9.3
  • Tcl/Tk 8.6.8

These are the Python and Tk that I already had installed on this system. My Tcl and Tk were built with threads (i.e. tcl86t.lib).

The internal headers were only in the source folder, they weren’t installed:

F:/Source/tk8.6.8/win/tkWinInt.h
F:/Source/tk8.6.8/generic/tkInt.h

Since they are in two different folders, but VTK allows only one TK_INTERNAL_PATH, it is necessary to create a new “internal” folder with the contents of both “win” and “generic”.

Also, the version of Tk must have the same major.minor version numbers as Python’s tkinter:

Python 3.9.3 (tags/v3.9.3:e723086, Apr  2 2021, 11:35:20) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> print(tkinter.Tcl().call("info", "patchlevel"))
8.6.9
4

Thank you for the swift answer. After your initial reply, I realized that I indeed built the TCL/TK 8.6 version on Linux. At first glance, it seems that Tk_Offset used in the VTK module is deprecated since these changes of tk.h. I will look into it tomorrow.

I am not very familiar with building using vc++. Which flags did you use to build tk for 64bit machines? Did you configure using the bash file?

5

I’ll check tonight to see what flags I used.
I didn’t use bash, I just used the cmd shell and nmake.
It was a long time ago, probably 2017 or 2018.

6

I couldn’t find my old build folder for Tcl/Tk (must have deleted it), but a brief reconstruction of how I did the build is roughly as follows:

  1. start a cmd shell
  2. run “vcarsall.bat x64” to set up the VS2017 command-line environment
  3. cd into the tcl8.6.x/win directory
  4. run “nmake -f makefile.vc release”
  5. run “nmake -f makefile.vc install INSTALLDIR=F:\Programs\Tcl86”
  6. do the same for tk8.6.x

The flags were the default release flags in the makefile: -O2 -GS -GL.
The installdir “F:\Programs\Tcl86” was just my preference.

7

Thank you a lot. I managed to build the needed vtk module!

In another thread you mentioned that copying the .dll into the site-packages is sufficient. While this worked for me on Linux, Python does not manage to find it on Windows (tries to load it in vtkLoadPythonTkWidgets.py). Do I need to generate any other files?

8

It’s possible that the DLLs it needs aren’t in the PATH. It will need the VTK DLLs, which are usually placed in site-packages/vtkmodules so that the VTK .pyd files can find them. The vtkRenderingTkXX.dll, however, won’t be able to find them there unless site-packages/vtkmodules is in the PATH.

Other than the VTK DLLs, I don’t think that vtkRenderingTkXX.dll needs anything except for the Tcl and Tk DLLs, and my understanding is that tkinter automatically sets the path for those, since they’re packaged with Python itself.

There are dependency trackers that can figure out which DLLs are missing, if you need one then I can check to see which tracker I’ve been using (my machine is at home, so I don’t have access to it right now).