Support building on Windows

[nightlark]

This has most of the changes that would be needed to support building on Windows using MinGW. Tests are not passing yet (some weird open file handle limitations on the GitHub Action VMs?).

The biggest limitation is that shell filters needed to be disabled since a native POSIX compatible ‘sh’ isn’t really available on Windows, and the forking/exec/pipes to spawn the subprocess are tricky to convert.

There are several things related to file access and temp file creation could be cleaned up by using std::filesystem.

Memory mapping and a few other read functions can be addressed with some Windows alternatives, though there may also be opportunities to leverage more C++17 standard library features to make those parts of the code more portable. And there are a few things like madvise that just don’t seem to have a Windows equivalent.

[prusswan]

is this testable right now? very keen to include this into our Windows toolkit

[nightlark]

Currently the code compiles as part of a Windows CI job using MinGW -- the artifact attached to https://github.com/nightlark/tippecanoe/actions/runs/11786378380 static links libstdc++ and libgcc, though you may need to track down several other libraries in order to run it on your system.

Your best bet to try testing it would be to clone my fork and check out the add-windows-ci branch, then compile it yourself using MinGW (or MSYS2 perhaps). The two mingw packages you need as dependencies are mingw-w64-x86_64-toolchain and mingw-w64-x86_64-sqlite3 (if building for an MSYS2 target instead, change the package names installed as needed).

Based on the current results of CI test runs, it is very likely to crash due to a segfault/memory access violation.

[prusswan]

Based on the current results of CI test runs, it is very likely to crash due to a segfault/memory access violation.

I was able to build it with MSYS2. Interestingly, while in the MSYS2 prompt, the error message reads: Segmentation faulty: 3%, but in the regular command prompt, the same message shows up as Reordering geometry: 3%. This is the last line, with no other error messages shown.

If it matters, the test file I used: tests\pmtiles\hackspots.json

Update:

tippecanoe-decode.exe is working so it is able to read from mbtiles at least

Update 2:

mapbox/tippecanoe#81 might be useful, if you haven't seen that already

[nightlark]

Good to know at least some parts work. I haven't seen the linked issue before -- the two things that stand out as potentially most relevant for the segfault is the use of variable length arrays (maybe on Windows those could be replaced by allocating a vector or calling alloca for allocating memory on the stack), and the immediate deletion of temporary files to make them anonymous.