MLPack solution build error in Visual Studio 2017

[VarunPai]

I was trying to build MLPack using Visual Studio 2017. I could successfully generate the VS solution (mlpack.sln) from CMake but I am facing these errors while building the solution.

I followed the instructions from this link (https://keon.io/mlpack-on-windows/) with few customizations. I used these configurations

1. mlpack 3.0.0
2. Visual studio 2017
3. CMake ver 3.11.1
4. Armadillo 8.5.0
5. boost libraries 1.64 (used nuget)
6. OpenBLAS (0.2.14.1) (used nuget)
   Also I have Anaconda 5.1 with python 3.6.4 installed in my machine. (Added to System Path)

Is there any idea what could be the reason for this error ? It seems that the error is from python bindings. how this could be solved ?

[zoq]

If turning the python bindings off is an option, I think this is the easiest solution for now; I'll have to take a closer look into the windows build issue.

[rcurtin]

Right, when you configure with CMake, try setting BUILD_PYTHON_BINDINGS to OFF. That should at least get the core library and command-line programs building.

[VarunPai]

Thank you @zoq and @rcurtin. Turning off the Python bindings solved the issue for now.

[gmanlan]

I spent some time reviewing this issue by replicating the Windows build using BUILD_PYTHON_BINDINGS=ON. Unfortunately, I can't reproduce the issue using VS2017 15.7.3.

I also noticed that the "generate_pyx_" projects include a post-build event that may fail if the user doesn't have enough privileges (error MSB3073 means that either VS can't find the setlocal command or that the paths referred in the command - like C:\Program Files\CMake... - can't be accessed by the current user). Because of this failure, the "build_pyx_" projects fail in consequence.

I guess it's just something that might happen under some particular user environment circumstances, not necessarily meaning something is wrong with mlpack.

@zoq, @rcurtin hopefully this helps to either close the issue or continue the investigation.

[rcurtin]

Hmm, so the post-build event does depend on the user being able to call the CMake program. (if I remember right it's just ${CMAKE_COMMAND} -E <some stuff ...>)

Do you think it's a common situation that the user will encounter that the CMake program might not be available? If so we can maybe try and work around it (or simply detect earlier on if the CMake program is accessible and disable Python bindings if not), but I'm not 100% familiar with Windows development so I don't know what the best thing to do would be.

[gmanlan]

I'm not really sure if the post-build event is exactly where it fails, or if it goes deeper into the referenced 'python_copy' project (I tried executing the script in isolation, and I get setup.py errors related to paths)... E.g.
ValueError: path 'C:/mlpack/mlpack-3.0.2/build/src/mlpack/bindings/python/' cannot end with '/'

But I don't really understand the entire python workflow yet...

[rcurtin]

Huh, maybe it could be this?

htrc/HTRC-WorksetToolkit#19

If you're willing to experiment, you could try changing line 98 of src/mlpack/bindings/python/setup.py.in from

      package_dir={ '': '${CMAKE_BINARY_DIR}/src/mlpack/bindings/python/' },

to

      package_dir={ '': '${CMAKE_BINARY_DIR}/src/mlpack/bindings/python' },

The trailing slash might also need to be removed on lines 39 and 58, not sure. I don't have a good way to reproduce either so I can't do the test myself. :(

[rcurtin]

Closing for inactivity---reopen if needed. :)