2016-01-21 16:28:03 -0600 | answered a question | Failure to build Python bindings under mingw32 While cmd.exe may work, the need to use Windows scripting may prove a dealbreaker for some, from both portability and sanity perspective. Luckily, there's an alternative solution I've found: 1) Do not use cmake on mingw/msys. Instead, rely on cmake version installed on Windows host. 2) Use -G "MSYS Makefiles" when invoking cmake In this configuration things seem to work much better. |
2016-01-21 06:00:01 -0600 | commented question | Windows/mingw installation problem Looks like the latter can be controlled with PYTHON2_PACKAGES_PATH (still doesn't explain the difference in defaults between the two OSs, though). Still looking at the first one. |
2016-01-20 22:53:33 -0600 | received badge | ● Editor (source) |
2016-01-20 22:47:24 -0600 | asked a question | Windows/mingw installation problem It seems that on Windows (mingw), instead of being installed into $(CMAKE_INSTALL_PREFIX)/lib libraries end up in machine+architecture dependent folder, e.g. if CMAKE_INSTALL_PREFIX is "C:/prj/INSTALL", I see: Additionally, Python2 module instead of being created in $(CMAKE_INSTALL_PREFIX)/lib/Python2.7/site-packages like happens on, say, OSX, ends up being installed into Python's installation folder: Is there a way to make both behaviors consistently respecting CMAKE_INSTALL_PREFIX across multiple OSs? |
2016-01-19 11:02:19 -0600 | commented question | Failure to build Python bindings under mingw32 So, if not msys, what would be your shell of choice on Windows, then? |
2016-01-19 10:54:13 -0600 | commented question | Failure to build Python bindings under mingw32 Yes, msys shell is being used. That (or cygwin) is the common way of using mingw on Windows, isn't it? The problem wouldn't have occurred, if the list of files was passed inline (msys/mingw converts the paths), rather than via file. Or if relative paths were used. Can either of these options be entertained? |
2016-01-19 10:27:39 -0600 | asked a question | Failure to build Python bindings under mingw32 OpenCV 3.0 fails to build with the following error: The file in question (core.hpp) is present in the location being looked at, but I'd guess the problem is that the paths are provided to Python in mingw, rather than standard Windows form. Is there a way to build OpenCV under mingw? Seems to work just fine, as long as Python bindings aren't required -- but when those are needed things go downhill fast. The final config status reported by cmake looks like this (more) |