[WIP] Windows platform support

[tehKaiN]

Not ready yet!

[matteblair]

😂

[matteblair]

Hey thanks for all the work on this port @tehKaiN ! Windows support has been missing for too long. I especially appreciate the documentation for different compiler toolchains.

It's been difficult to find time for code review on this because our core team only has macs during working hours, but I will commit that this weekend I'm going to spend time trying this out and hopefully we can get this merged.

[tehKaiN]

How's it goin'? ;)

[matteblair]

https://github.com/tangrams/tangram-es/tree/windows-v2

My goal here has been to get the sample app working with Visual Studio - since that's the only build toolchain that I really use on Windows :D It doesn't seem impossible, but there still some build issues with the Mapbox Variant submodule I need to figure out.

One thing that simplified the build process greatly for me was using Conan to manage library dependencies like Zlib and libCURL. On Windows the complexity of managing binary dependencies is great enough that something like Conan actually makes sense, and it worked exactly as advertised.

[matteblair]

In regards to merging these windows changes, I don't mind merging things as they are and continuing to work on the build configuration incrementally. This work is almost totally separate from the other platform targets, so there isn't much risk of breaking something else.

I think it will be important to add a CI configuration (probably Appveyor) to check our Windows builds regularly. Otherwise, we're just going to break Windows all the time - since none of us maintainers work on Windows.

@tallytalwar @hjanetzek Thoughts?

[tallytalwar]

FYI, I also started looking at this at my home pc. More eyes the better. Will update more this week.

[tallytalwar]

Ahh, just saw your mention @matteblair.

We should give it a proper look before merging this in master, as we have spoken before, once in master it will be officially supported. Probably add some WIP/Beta with it in the windows platform readme. That being said, totally cool with this being merged, but maybe give me a week(ish) time to finish whats in here.

For CI yes, Appveyor is good, I think we did play with it for the previous attempt of merging windows in. Will also be good to add unit tests support for the same and not just the builds.

[tehKaiN]

I'm fine with that as long as it gets merged eventually. ;)

I think I'm done here. Is there anything else I should do for this PR?

[tallytalwar]

Tiny update.

Thanks @tehKaiN for documenting this PR so well, specially all the possible windows platform toolchains. I have the basic setup done on my home machine and plan to finish reviewing this the following week.

I agree with @matteblair about having dependency management (can be added as a subsequent PR) and CI (with this PR or immediately after this, though should not be too hard).
On the GL front, I am happy with the usage of GLAD. Less unsure of whats tangram's future with gl library is in lieu of iOS deprecating opengl-es, but GLAD is totally fine for our purposes right now.

More to followup next week on this.

[tehKaiN]

Guys?

[tehKaiN]

I see that now there are conflicts in some files. If anyone is willing to review my changes and eventually merge them I can fix them for you.

[karimnaaji]

@tehKaiN @matteblair @tallytalwar I can review this branch if there is still interest in getting windows platform in main.

[tallytalwar]

@karimnaaji go ahead please :D.

[tehKaiN]

@karimnaaji the file structure and build system has changed a bit since beginning of this pull request. You want me to make this stuff compatible with master, or would you like to do it yourself?

[karimnaaji]

@tehKaiN no it's ok since I think the consensus was to use Conan so I'll directly start from main to use it for the build, and add your code changes on top.

[tehKaiN]

@karimnaaji I've added required changes on top of recent master since I need this lib for my company's app and I like to be sync'd with latest stuff. You can look at it here: https://github.com/tehKaiN/tangram-es/tree/windows-v3

Unfortunately there are some crashes as I've recently described in #1569 which weren't present before.

I was hoping for wxWidgets platform support which I have implemented too, but I think incorporating it to your repo won't work in the long run - I'll refactor it as a lib with libtangram as dependency when this pull request is over.

[karimnaaji]

@tehKaiN sounds good! So far I've rebased the branch locally, and tried a few things:

• MSVC+Conan: I really wanted to get MSVC build with Conan working but I think there would be a lot of complications from it for this repo, as most of the dependencies Tangram relies on are not supporting that toolchain, this would result in being a pain to update those upstream every time. The advantage from that is that there is already the built dependencies Zlib/Curl/OpenSSL available on the Conan servers.
• Conan+MinGW gcc: I've tried using Conan with MinGW gcc and build Zlib/Curl/OpenSSL from source with a custom profile (since Conan doesn't have libraries pre-built for MinGW), but Conan didn't really like that and was breaking in their generated compilation python code, which seems like something we could report on https://github.com/conan-io/conan but for now I think the solution you had was the simplest (MinGW + manually built dependencies), though not ideal as this is not the most common toolchain setup. Maybe not relying on Curl at all for that platform would be the best (in a later step).

[tehKaiN]

@karimnaaji perhaps it'd be simpler to make it work with bare CMake in same way as rest of platforms are supported. You can resolve CURL/zlib dependencies by building them using CMake and then using mingw32-make install as mentioned in windows platform readme on my branches.

Having libs installed in predefined directory simplifies things a lot, just don't use default install path (Program Files) as it requires elevated privileges. I think it's a way to go and I'd really like to have libtangram properly installed in similar manner so that other projects can use it without incorporating it as submodule and directly building using project's build process.

And yes, forget about MSVC for now as its support for latest C++ is a pos. Even Microsoft adds Clang to Visual Studio installers, and there's no coincidence in that. ;) Unfortunately Clang on Windows uses MSVC compatibility mode instead of GCC one as on rest of platforms, which I haven't figured out how to disable.