prebuild h3-node

[dfellis]

@isaacbrodsky @isaachier If either of you have some time or experience with CMake Windows issues, could you guys help me figure out why my x64 Windows build is producing an h3.lib file with no exported symbols? What's particularly perplexing is how it works perfectly fine for x86.

[dfellis]

I've got a thread to pull on this -- it may be that the H3 code is still being compiled in 32-bit in the Windows x86-64 path and therefore won't link with the N-API code being compiled in 64-bit.

I can't work on this until the evening, but logging this here in case @isaacbrodsky has any ideas what CMake option I need to set for H3 to compile a 64-bit lib might be. ;)

[isaacbrodsky]

Hi @dfellis

I'm not sure why CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS needs to be set in your CMake invocation, since it should be set by CMakeLists.txt. When I tried with it on or off from the command line, it didn't seem to have an effect. It shouldn't hurt though.

I tried both of these:

cmake .. -DCMAKE_VS_PLATFORM_NAME=Win64 -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=True
cmake .. -DCMAKE_VS_PLATFORM_NAME=x64-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=True

and I wasn't able to get it to build a x64 binary. I'm guessing this is because CMake defaulted to using the x86 MSVC toolchain, so it was ignoring the platform name. In the uber/h3 appveyor.yaml, the generator is set directly rather than using CMAKE_VS_PLATFORM_NAME.

I tried instead:

cmake .. -DCMAKE_VS_PLATFORM_NAME=x64 -G "Visual Studio 15 Win64"
msbuild h3.vcxproj

and then to verify:

dumpbin /headers bin/debug/h3.lib | findstr "machine"
dumpbin /symbols bin/debug/h3.lib | findstr "h3ToGeo"

This seemed to produce a valid 64 bit h3.lib.

(note: I'm using Visual Studio 15 aka 2017, but I assume this works the same for 14 aka 2015)

[dfellis]

@isaacbrodsky you're amazing as usual! I'll test this out this evening and hopefully after that there'll be an h3-node on NPM that can be installed by most users without needing to install the build toolchains. :)

[dfellis]

Success!