@ben.boeckel, this merge causes a build failure wrt Python wrapping in Windows.
It seems the linker is unable to find the Python library:
LINK : fatal error LNK1104: cannot open file 'python37.lib'
I can get a build if I set VTK_PYTHON_OPTIONAL_LINK to OFF.
This popped up a while back in VTK_PYTHON_OPTIONAL_LINK
Hmm. Our Windows Python builders are OK with it. That line seems to indicate that there is autolinking going on somewhere. Maybe this is new in 3.6? I think we only test up to 3.5 now and Windows is a 3.5 tester.
Hrm, yep, I see autolinking in pyconfig.h. There’s no way to disable it either 
. Seems we have to disable its addition either 
. Though it isn’t new in 3.6 either. So I guess the question is: why is it working on mun?
@ben.boeckel I hope you find out what’s happening on mun! I spent a lot of time trying many things, including deleting everything and rebuilding, and I was even considering reverting to an older version of Visual Studio as a last resort. However when I was writing this post, Discourse picked up the older post I referred to. So I was able to build based on the comments in that! So Discourse works!
One other thing is that I am using Anaconda Python, but that shouldn’t matter.
Well, Anaconda (frustratingly) tends to build their Python versions differently than python.org binaries (which is what we’re using). @danlipsa did you encounter any Windows issues with the Anaconda VTK you were working on?
I have not tested on windows. We don’t use Windows packages but rather Unix packages under the Windows’s Unix subsystem.
On windows, it is indeed required to link against the python library, there are no use of weak linking and the python shared library is always distributed 1, 2
1 This is always true when dealing with a CPython distribution able to load python modules.
2 In the case of statically built CPython distribution, no shared library would be available but that is an unrelated usecase
OK, so we should then add NOT WIN32 to that conditional then.