Support for Windows

[mbudisic]

If we want to support Windows, perhaps the best route is to learn to use a virtual machine manager, install Win/Matlab/GCC there and use it for generating binaries and/or testing the installation.

Suggestions for cross-platform VM. https://www.virtualbox.org/ http://wiki.qemu.org/Main_Page

[jeanluct]

Yuck... that sounds like a lot of work. I would prefer having a volunteer who uses Windows.

[mbudisic]

Full disclosure, I am now using a Windows machine. Haven't tried compiling braidlab yet, but I think I can pick off #112, at least to a certain degree (if larger issues surface, oh well)

[jeanluct]

Go for it! But I think this is major enough that it should be in 3.3 or 4.0. I would expect 3.2.1 to only fix issues and introduce little new functionality.

[jeanluct]

Discussion between me and Giuseppe Di Labbio:

GDL:

Anyway, I am not sure if you have attempted to compile braidlab on Windows (since I haven't seen it in the guide), but I have succeeded in doing so with minimal steps (with GMP included). While I have been using braidlab on Ubuntu at work, now that I have to work from home, connecting to my office computer remotely is often too unstable. Therefore, motivated by my frustration, I took some time this past Friday to get it to work on my laptop which runs Windows 10. After compiling, when I ran test_braidlab.m, all 51 tests passed.

Basically, I installed MinGW-w64 (using MSYS2) along with the necessary GCC and GMP packages and linked MATLAB's MEX compiler to it. Effectively, I had to follow what was done in the makefiles closely. This amounted primarily to compiling what was in the "cbraid" and "trains" folders using MinGW-w64's g++ (I also had success doing this with the Windows Subsystem for Linux, Ubuntu) and then compiling everything else with MATLAB's mex command making sure to use the same flags/options you use (I put it all in one m-file, so it is kind of like a "make" but performed within MATLAB). I also had to do some very small changes, like explicitly include header files in cross2gen_helper.cpp and loopsigma_helper.cpp (since they where included via the makefile originally). I also had to explicitly #define _USE_MATH_DEFINES in randomwalk_helper.cpp (because MinGW-w64's gcc/g++ doesn't recognize things like M_PI by default). MATLAB does have its own compatible MinGW-w64 version which can be downloaded for free from its App store, but I don't see how I can get GMP with it, which is why I went with MSYS2 (and I seem to have been successful). With MATLAB's own MinGW-w64 compiler, I was at least able to compile everything in the same way and everything works the same way, but without GMP. If I can figure out how to get GMP with MATLAB's MinGW-w64 compiler, that would probably be the best option for braidlab for Windows. If I contact support, perhaps they can give me some information about it.

J-LT Reply:

If you're interested we could work to add the necessary headers, etc., but I can only help so much since I can't test on Windows. We could then add the instructions in the appendix, or even if you were interested you could provide binaries for posting on on Github.

GDL:

In terms of headers, I honestly didn't really do much to get it to work, all I did was three very small modifications (see the bottom of this email). Other than that, nothing actually changes from what you already have :) I just don't use the makefiles, I replace them instead by a single MATLAB script (which requires MinGW-w64 to run). Actually, out of curiosity, I just remotely transferred my compiled braidlab folder (with the mexw64 files, since it's Windows) to a Windows computer in my office. It worked right away without having to recompile or download anything (my laptop has MATLAB 2019b while the computer in my office has 2019a). In terms of providing those files directly (if that's what you meant), I imagine it should be fine. I put the files on my Google Drive in a zip (link below). The braidlabWin10.m file is what I used to compile everything (after first compiling the "cbraid" and "trains" stuff using MinGW-w64's g++, which I will write a few steps for soon I guess).

---

1) In randomwalk_helper.cpp:

• Add the line #define _USE_MATH_DEFINES before #include
• Reason: MinGW-w64 doesn't recognize M_PI by default. 2) In loopsigma_helper.cpp:
• Explicitly add the lines #include "update_rules.hpp", #include "sumg.hpp", #include "ThreadPool_nofuture.h" and #include "ThreadPool.h"
• Reason: They were originally included via the makefile I believe, but since I had to bypass the makefiles, I explicitly added the #include statements. 3) In cross2gen_helper.cpp:
• Explicitly add the lines #include "ThreadPool_nofuture.h" and #include "ThreadPool.h"
• Reason: Same as previous.

J-LT:

The header file changes are easy enough. I don't think it's the Makeflles that include them. It must be a different way the C++ compiler on Windows has of treating chain includes. But I don't think it will hurt. I'll test it once you add to the issue.

On the other hand it would be good to get the Makefiles working if we're going to support Windows. There's no Makefiles on Windows?

GDL:

At the very least, this is a temporary and seemingly fully functional way to compile braidlab on Windows.

On Windows, there are makefiles and they can be compiled via "nmake". There are of course differences in terms of syntax with makefiles on Unix though (see for example https://cognitivewaves.wordpress.com/makefiles-windows/). The differences don't seem to be huge, but the file types of course change too. Specifically, where Unix uses ".a" and ".so" Windows uses ".lib" and ".dll". Also shell scripts in Unix are generally equivalent to ".bat" files in Windows and compilers must be specified using their ".exe. extensions. Unfortunately, I myself am not familiar with writing makefiles on Windows (which is why I took this approach), but I have successfully compiled them in the past (to compare, there is https://github.com/vlfeat/vlfeat who have separate makefiles for both Unix and Windows). This way would use the MSVC compiler (Microsoft Visual Studio C/C++ compiler), so using GMP may be tricky (there are some equivalents though, which I am personally not familiar with, namely, MPFR and MPIR).

The other approach for makefiles on Windows would be to go through MinGW-w64 which uses the GCC compiler. I found https://stackoverflow.com/questions/8552580/using-gcc-mingw-as-matlabs-mex-compiler before, which I was about to try out before doing what I did. Perhaps it is the way to go! I will check it out this weekend.

[jeanluct]

Ok, I created a iss112-support-for-win branch. I added Giuseppe's script to the devel folder, and made a quick devel/makedist.win script to package the binary. I added the binary to the release: https://github.com/jeanluct/braidlab/releases/tag/release-3.2.4

The extra #include's suggest by Giuseppe are wrapped behind a flag BRAIDLAB_WIN that will need to be enabled during compilation, at least for now. I'm still not sure why these include's are needed. loopsigma_help.cpp, for instance, doesn't even use sumg directly.