compiling on windows

[rhambach]

Dear ahbarnett,

thanks a lot for your demo files for MWrap. As I have to work with Windows, I added some Makefiles for NMake to compile Mwap-0.33.3, the examples of Mwrap, as well es your demo files for c and c2domp. They worked for me (Windows Server 2012), but I guess one should cross-check them on a different Windows system and test the Linux and Mac version again, as I had to make some changes in the code. But maybe it is already a good starting point for adding Makefiles for Windows.

Best, RHambach.

[ahbarnett]

Hello Ralf,
Thanks for doing this - I look forward to merging your changes! However, there's some stuff I'd love us to chat about first, so that the repo preserves some of my original goals:

1. I'd really like to keep your new C++ examples separate from the C examples. This keeps the latter as simple as possible. Eg if you want to mwrap an existing scientific library, you won't want to be introducing mwSize objects into the library source; rather you'd want to leave it in pure C if it came that way. Likewise for the C++ complex type (which I don't use). Would you be able to create cpp and cpp2domp directories for your examples? (Now, it could be that windows breaks unless you use mwSize, C++ complex, etc ... let me know if true and we have to rethink).

2. I haven't had time to test it out yet (pull requests are new for me). Maybe I'll wait until we decide on point 1?

3. You have made a lot of changes to MWrap itself (way beyond what I understand). These should be also sent to Bindel, the author, for his consideration. I am happy to keep this locally-hacked MWrap here, as long as we state that it's been changed to work with windows (right? all those changes were to get that working?), but if Bindel ever updates (he probably won't since he hasn't for a few years), we'll be stuck.

4. This is minor, but, the trailing double-spaces in the README.md are part of markdown and cause a CR (carriage return) iie new line. So I would reinsert them.

What do you think?
Best, Alex

[rhambach]

Dear Alex,

I would like to briefly answer your comments/questions in random order

2. I guess it is worth checking first, if I accidentally broke compilation on Linux/Mac by some changes. If it is not easily repairable, one can probably save the time for merging. I am sorry that I cannot perform these tests myself.

3. I actually introduced only very few changes in MWrap. Most of the highlighted differences are due to the automatically generated files mwrap.cc and lexwin.yy.cc as I have used a newer version of Flex/Bison (v.2.7 instead of v2.5, all changes are included in commit e9b5bb4). The actual source files mwrap.y and mwrap.l have only very few changes. I summarized the actual changes below (see description of commits):

• a5efd1a compiler complains about missing return 0; in yyerror
• b3cdb8c switched to C++ compiler, renaming .c->.cc, adapt references to external symbols (EXTERN_C)
• b8a70b9 correct small bug in MWrap in typedefs for mwSize, ...

1. Switching from C to C++ was necessary for Windows, as the Microsoft Visual Studio C compiler does not support complex numbers at all (see link). I did not want to mix C and C++ compilation, so I switched completely. Pure 'C' examples with complex numbers thus would not work in Windows. The renaming of the files to .cc is convenient on Windows, as the compiler does not recognize .C or .cpp, but probably one should revert this as it is quit unusual under Linux/Mac.

I did not completely understand your comment on mwSize "objects". As far as I understand, mwSize and co are just typedefs for int or size_t and should be used both in C and C++ (see link).

4. I am sorry. I did not pay attention to the white-spaces at the beginning and probably forgot to restore all of them.

Best regards, Ralf.