Superbuild Python version riddles

Development
1

Again talking about the superbuild I am working with, now still with MSVC2013, PV 5.5.0 and adapted Qt5.9.1, and working with Python 2.7.

The superbuild goes through, but during the packaging I am getting the following message:

Failed to install pvdataserver:
Traceback
[…]
RuntimeError: Unable to find the api-ms-win-core-rtlsupport-l1-1-0.dll library from […]

For me this looks like some Windows and/or MSC version issue, and the one thing that I really find is the fact that Python does not really look like being compiled with the same toolset that I am otherwise using:

The installed system Python tells the following on starting the console:
Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32

Also there is a newly compiled Python in my superbuild which tells me the following on startup:
Python 2.7.3 (default, Feb 14 2017, 14:49:11) [MSC v.1500 64 bit (AMD64)] on win32

What bothers me most is the fact that MSC v.1500 must be according to Wikipedia:

MSVC++ 9.0 _MSC_VER 1500 (Visual Studio 2008 version 9.0)

What I would rather expect with my actual MSVC would be version 1800!

Is this a known problem? In any case it looks weird for me that I find that “old” version of Python in the folder where I would expect the newly compiled stuff from the superbuild:

…/superbuild/python/src/bin/python.exe

(Although strange enough: this python.exe has a date/time stamp of 14/02/2017 - not really the time when my superbuild was running…

On the other hand: My initial error message did not tell me anything about Python, but about the pvdataserver…

Regards,
Cornelis

2

To fix this, you’d need these changes:
https://gitlab.kitware.com/paraview/common-superbuild/merge_requests/242/diffs

Essentially, the rules needed to be updated to not try to package these system files. These changes are already in for 5.6.

I am going to defer the Python question to @ben.boeckel.

3

Great - with this the package was successfully generated! Tomorrow I will certainly try to install them and run the software.

More precisely: I first applied the indicated patches, but it was already clear that I was not starting with exactly the right version. The result was some indentation error.

However, the “radical solution” - just replace the entire fixup.bundle.windows.py - made it finally happen.

Bottom line: The initial problem was obviously not a Python problem, but tomorrow I will try to find out which of the Python.exe was actually installed by the NSIS package…

Regards, Cornelis

4

Python2 only supports being compiled with the VS2008 toolchain (MSVC 9.0; yes the version numbering scheme for MSVC, VS, etc. is convoluted), so that’s expected. Because “no one” has such a toolchain laying around anymore, we just compile a Python here and ship that as a binary drop (it’s made with the prebuilt-python project in the common-superbuild for those curious).