This almost works by setting CMAKE_BUILD_TYPE:STRING=Debug except that the project generates python27.{dll,lib} instead of python27_d.{lib,dll} so that you get:

fatal error LNK1104: cannot open file 'python27_d.lib'

when trying to link the python executable.

Until this is done, WIN32 AND Debug should probably error out.

So…has anyone gotten a successful build of any kind on Windows from this build? It builds, but the install tree is unworkable. I'm getting the feeling that I'm doing things undone before here…

@jcfr @vibraphone

Few comments:

• CMake'ified python is build on daily basis on windows (it is used within Slicer).
• The debug build is not (yet) supported because on windows VTK, Paraview, etc ... always built against a release build python independently of the build config (Release, Debug, ...)
• Within Slicer we currently explicitly specify the path to include dir, exectuable and library .. that way the existing call to find_package(PythonLibraries ..) works as expected.

When you mention the install tree is unworkable, what do you mean exactly ? We made effort to match the layout obtained on windows after doing an install using the official python build system.

Alright, so there is some hope :) . What do you do about libraries needed by compiled modules which live beside python.exe? In my case, zlib is linked by binascii.pyd but installed beside the executable and therefore fails. It appears that python.org's installer doesn't even have a python27.dll, so that's another difference. Anyways, I need binascii for building numpy, so it isn't something I can just turn off.

It seems this issue is not specific to cmake'ified python.

To workaround this sort of problem and ensure the configure and build work as expected, within Slicer, there is are few concepts:

• instead of setting PYTHON_EXECUTABLE to the original python.exe, we pass a launcher named customPython. See [1]. The launcher will look for a settings file [2] that we also configure [3]
• since zlib is build statically, there are no issue on that side. On the other hand, OpenSSL is built as shared. And in that case, the setting are configured accordingly. See [4]
• Moving forward, the setting will be configured more automatically. Similarly to how it is done for the launcher settings associated with the Slicer executable. See r23724
• Finally, note that the launcher we used is statically linked against Qt and is pre-built for all platform we support. See [5] and [6]

[1] https://github.com/Slicer/Slicer/blob/7f471a37d7b168c419d2b923b821fd1dd7180199/SuperBuild/External_python.cmake#L149-L165

[2] https://github.com/Slicer/Slicer/blob/master/SuperBuild/python_customPythonLauncherSettings.ini.in

[3] https://github.com/Slicer/Slicer/blob/121d28f3d03c418e13826a83df1ea1ffc586f0b7/SuperBuild/python_customPython_configure.cmake.in

[4] https://github.com/Slicer/Slicer/blob/121d28f3d03c418e13826a83df1ea1ffc586f0b7/SuperBuild/python_customPython_configure.cmake.in#L78

[5] http://commontk.org/index.php/Tools:_Application_launcher

[6] http://packages.kitware.com/packages/application/view?applicationId=10

Note also that we build Numpy 1.4.1 every night.

There is also an experimental branch building the latest OpenBlas, NumPy and SciPy using a statically built mingw compiler. See https://github.com/jcfr/Slicer/tree/upgrade-to-numpy-1.9.0-and-scipy-0.14.0

Looking at the module ExternalProjectForNonCMakeProject may also be interesting.

An example of use is available here: https://github.com/Slicer/Slicer/blob/7f471a37d7b168c419d2b923b821fd1dd7180199/SuperBuild/External_NUMPY.cmake#L22-L113

I'll have to look into the launcher thing; that's probably the way to go. A batch file should do the trick for us; I don't think we need a complete configuration system for it since we only really need it for the build steps of numpy (and I don't think the other tools we build use any of the compiled modules during their builds) and after that pvpython is the expected way to do things which should work already. Not the prettiest setup, but it's really just to get binaries…

Unfortunately, static Qt and rest-of-stack is pretty much a no-go (I have enough headaches just getting Qt to compile normally without trying to stuff QtWebKit into a static library on a machine with less than 16G of memory…and Qt5 is around the corner…) since compiling static binaries of just ParaView already starts to push the memory limits when in a parallel build on my main machine, so we will need to support using shared libraries as dependencies of compiled modules.

As for numpy, 1.4.1 is likely way too old to apply here. We're using 1.6.2 and I'd really like to bump to 1.8.x (and upstream is at 1.9.2 already…). We're currently using a hacked up build which allows us to do a static build for ParaView to use on supercomputers (though numpy's build "system" is used for normal builds), but that isn't applicable to Windows anyways.