Add windows support

[tdcosta100]

I have specific needs to run Maplibre GL Native on Windows. So I created a port to Windows platform. It was inspired by Linux platform sources, and works in a similar way, creating some executables and the lib/node-vxx/mbgl.node modules. Therefore, Maplibre GL Native can be used with NodeJS in an Windows environment. I used TileServer-GL to test it, and it worked like a charm, the performance was similar to the Linux version. Build instructions are located at platform/windows/README.md. Remember to clone with --branch windows-support, because it have a new submodule. Or after changing to windows-support branch, you can init the platform/windows/vendor/vcpkg submodule manually. Feedback is welcome.

[wipfli]

Oh beautiful, thanks @tdcosta100 for implementing windows support.

If we were to merge this, would you be interested in being the lead-maintainer for the Windows platform binding?

The usual work consists of handling dependency updates, reviewing pull requests, and helping people getting started with the platform binding...

[tdcosta100]

Oh beautiful, thanks @tdcosta100 for implementing windows support.

If we were to merge this, would you be interested in being the lead-maintainer for the Windows platform binding?

The usual work consists of handling dependency updates, reviewing pull requests, and helping people getting started with the platform binding...

I think I can try. I'm just afraid sometimes I will be with lots of demand from my job and not respond so quickly as I would like. Outside these situations, I think I can do the job. Can we make a trial period to see if I am a good fit for it?

[ntadej]

Thank you very much for providing this!

I provided some basic comments, I may look through the new files again later. To get this merged faster I would recommend to split the MR into smaller ones (e.g. fixing errors).

It would also be good to add a CI workflow to test your addition actually works.

[tdcosta100]

Thank you very much for providing this!

I provided some basic comments, I may look through the new files again later. To get this merged faster I would recommend to split the MR into smaller ones (e.g. fixing errors).

It would also be good to add a CI workflow to test your addition actually works.

No worries about the changes. I can change everything, even open a new PR if it's better. I would propose this project to be evaluated before doing a PR, but I just didn't know where to do that hahaha. So if it's not mature enough, I will make the necessary changes before the merge.

Regarding the CI Workflow, I agree. I will try to setup the Windows workflow. I'm newbie to this, can I setup a workflow in a non-main branch?

[wipfli]

can I setup a workflow in a non-main branch

Yes, like this for example

on:
  workflow_dispatch:
  pull_request:
    branches:
      - main
      - some_other_branch

[acalcutt]

If you need any help with getting this into the node-ci/build, let me know. It would be nice to add node windows support.

If you modify the node-ci workflow in the PR it is already set to run on pull request, so I don't think you would need to modify the branches it runs on. (at least that was how I was testing it before it got merged)

[tdcosta100]

This is interesting! I will try it.

can I setup a workflow in a non-main branch

Yes, like this for example

on:
  workflow_dispatch:
  pull_request:
    branches:
      - main
      - some_other_branch

Nice, thanks!

[tdcosta100]

Once all pending changes to prepare for this PR are finally done (that is, changes that are not directly related with Windows, like Khronos definitions, and implicit casts), I'm resuming this PR. I converted it to draft in order to test actions for NodeJS on Windows platform. I didn't include actions yet, but once all tests passed, I will focus that.

[acalcutt]

I spent some time working with @tdcosta100 to try and get this integrated into the 'node-ci' and 'node-release' workflows

We were able to get it all working, but I wanted to note a few issues we had along the way.

1.) When checking out the the repository on the github windows runner, I ran into path limit issues with some vendor test files. To get around this, I took a solution from the 'qt-ci', and did a shallow checkout and then pull the submodules after. This gets around the issue, but you can still see some errors relating to the paths that don't affect the build.

2.) To get ccache working in windows, I again pulled from the qt-ci, and used that to simplify our ccache use here (and make it work with windows).

3.) We initially had some issue with build type not being release, which made it this require c++ development dlls. we fixed that issue, but it should still be noted this requires c++ redistributable as a pre-req

Other than that, I was able to ci/release workflow that works.

I made a test release at
NPM: "@acalcutt/maplibre-gl-native": "6.1.0-pre.4"
https://github.com/acalcutt/maplibre-gl-native/releases/tag/node-v6.1.0-pre.4

and a tileserver-gl that uses it at
https://github.com/acalcutt/tileserver-gl/tree/windows_test

With that I was able to confirm this works!

Great work @tdcosta100

[tdcosta100]

A huge THANK YOU to @acalcutt, who spent so many hours trying to adjust node-ci and node-release workflows, and succeeding at this painful job.

Regarding the too long path issues, I confirm it's resolved, at least when cloning submodules (recursively!). I don't know how tests will behave because I didn't let a test job finish yet, but I hope in the next few hours we will confirm if it works correctly.

[tdcosta100]

Finally got Windows tests working. Thank you @acalcutt again, for helping with the workflow.

[tdcosta100]

Could you update the root README.md:

- [⭐️ Android](platform/android/README.md) 
- [⭐️ iOS](platform/ios/platform/ios/README.md)
- [GLFW](platform/glfw)
- [Linux](platform/linux/README.md)
- [Node.js](platform/node/README.md)
- [Qt](platform/qt/README.md)
- [Windows](platform/windows/README.md)
- [macOS](platform/ios/platform/macos/README.md)

Done!