Add support for compilation on Windows using VS or MinGW
There already is a effort underway to make this run on Windows. Why do you propose a second one?
A few things I've noticed:
- Typo in the first commit
- PR is based against master
- You're linking against OpenSSL in your VS project files. This calls for trouble, due to the licensing issues. The older Windows port already solved this, since there's a
--disable-opensslswitch in the test branch. - The VS xml files (9df0d7b) are very intrusive. Isn't there a smaller build system overhead?
- Your config.bat looks auto-generated. Add source and instructions how to re-generate.
-
_PRINTF_INT64_is not a portable way of doing it. The other PR already solves this portably. - There are a lot of modifications and parallel, nearly duplicated code sections. The existing approach also does this, but isn't as bad.
- Solving portability problems by simply adding a few
(int)casts is great if you only run it on your own machine. However, this code will run on lots of machines.
In essence: Thanks for trying to make tgl Windows-ready! But it would have been much more effective if you work together with the existing efforts.
The previous pull request #62 does not work under msvc, so this proposal also adds support for Microsoft C++ compiler. Maybe I should have made it more clear. It's based on master branch because our project requires a stable version. If there is a request for Windows/MSVC support in general I am willing to re-base it to test branch.
To answer your other inquiries:
- Sorry for the typos there.
- I did not know there was a licensing issue with OpenSSL but master branch does not work without it. This will be fixed if moved to test branch.
- Vs xml, the usual practice with visual studio is to go with the project file. However, there is msvc nmake, a Unix kind of make tool but it does not support unix makefile. Maybe it could be ported somehow, I've never tried it . Suggestion: it would be easier if tgl supported cmake-like cross platform project generator.
- config.bat was not auto-generated. I based it on what configure and makefile do.
- PRINTF_INT64 is done the same way as previous pr #62
- The code in general was not modified at all. There are more additions to the code rather than changes of the original code. MSVC unfortunately does not support much of the Unix/Ansi C API functions or those functions have been deprecated. There are also cases where equal functions require additional parameters under winapi. That is why there are so many added preproc wrappers that solves this problem and it is hard to do it any other way.
- Sorry for the casts. They should not be there, will fix it.