Since weeks now I am struggling with the fact that since some time, my Superbuild for a ParaView custom application does not properly include the Python runtime any more. All is done on Windows 10, because that is what my customers are using. This happened when I switched from underlying 5.8.0 to 5.9.1, but I also did changes in my own code.
After a lot of research with versions when it still worked and the current one, I found out the following:
-
A functional Python3 runtime in an installed software includes c:\Program Files\MySoftware\bin\python37.dll (or whatever version), plus subdirectories named Lib and DLLs with “a lot” of content. A non-functional Python3 runtime has only the dll plus a Lib with not much content - to put it a bit simple. Symptom when trying to do something in the Python shell in the “new versions”: Click into the shell - and the program crashes. It does so inside the python.dll when trying to initialize: Looks like it is looking for that missing stuff. If I add it manually into a buggy installation, the Python subsystem works. This was the state when I realized that something is going wrong - and I started to check and manipulate the different configuration files until I came “one step further” - as follows:
-
In my superbuild target directory, there is a subfolder named /install. If I choose to not use a local Python system, some source code of Python 3.8 is downloaded and built, and the result ends up in a subfolder of this /install folder: /install/Python. This contains python.exe and dll, plus the mentioned subdirectories and many more. It is possible to run Pythin from a command line inside this folder, so this seems to be a fully functional Python system. To me it looks like it should eventually end up during the ctest -R … call all inside the _CPack_Packages/win64/NSIS/mysoftware/bin folder, but this does not happen. Instead I am right now getting a complaint during the CTest… run that some specific paraview dll does not find the python.dll that it relies on. The search path would include the install/bin subdirectory, so if the Python system was there and not in install/Python, it would be found. If I try the same using a functional local Python system (from OSGeo4W), I have there such a Python folder with the necessary subfolders, and I assume that somehow that stuff should be copied from there.
Bottom line: I do not get any further at this moment!
My assumption is that somehow the packaging process should FIRST somehow put the entire selected Python system to the destination folder (including dll and required subdirectories), either from the self-compiled output or from a local source, and only then try to put also any other stuff that relies on an existing python.dll. Or else, just copy that python.dll to the install/bin folder, to make that other script happy, and only then put the entire Python system into the package.
I hope somebody is able to figure out what my problem is without too much trouble, because that superbuild is pretty complex and I do not believe that there are lots of people around who understand it in such detail that they can easily answer my question! still I would be happy if somebody has some helpful hint.