Windows Binaries Path

[flippmoke]

Currently, the path for windows binaries seems to vary at times in ways that I did not expect. Depending on the settings at times it seems that the requested could be:

https://mapbox-node-binary.s3.amazonaws.com/mapnik/v3.6.0/node-v11-win32-x64-Releasev140.tar.gz

or

https://mapbox-node-binary.s3.amazonaws.com/mapnik/v3.6.0/node-v11-win32-x64-Release.tar.gz

I have not "nailed down" why this is happening, but notice the v140 that appears on the end. Currently our build system seems to be adding v140 on the end, however, some client requests do not seem to be requesting this path.

In our package.json this is set by the following line:

"package_name": "{node_abi}-{platform}-{arch}-{configuration}{toolset}.tar.gz"

Therefore, it seems that sometimes we are having a toolset set and other times we are not. In order to support both, I have simply copied on s3 our binaries so that we have both filepaths. I am not sure this is optimal or even correct.

/cc @springmeyer @BergWerkGIS

[flippmoke]

After copying current build out:

mthompson@flippmoke:~/src/node-blend$ aws s3 ls s3://mapbox-node-binary/mapnik/v3.6.0/
2017-04-18 13:11:46   29708671 node-v11-darwin-x64-Release.tar.gz
2017-04-18 13:00:46   31615741 node-v11-linux-x64-Release.tar.gz
2017-04-18 15:58:56   27705251 node-v11-win32-ia32-Release.tar.gz
2017-04-18 12:47:06   27705251 node-v11-win32-ia32-Releasev140.tar.gz
2017-04-18 15:59:20   29949661 node-v11-win32-x64-Release.tar.gz
2017-04-18 12:47:14   29949661 node-v11-win32-x64-Releasev140.tar.gz
2017-04-18 13:13:51   29682655 node-v46-darwin-x64-Release.tar.gz
2017-04-18 13:15:44   44284694 node-v46-linux-x64-Debug-asan.tar.gz
2017-04-18 13:04:02   37261199 node-v46-linux-x64-Debug.tar.gz
2017-04-18 13:02:04   31586730 node-v46-linux-x64-Release.tar.gz
2017-04-18 16:06:34   28236472 node-v46-win32-ia32-Release.tar.gz
2017-04-18 12:47:12   28236472 node-v46-win32-ia32-Releasev140.tar.gz
2017-04-18 16:05:49   30914909 node-v46-win32-x64-Release.tar.gz
2017-04-18 12:47:56   30914909 node-v46-win32-x64-Releasev140.tar.gz
2017-04-18 16:06:46   28236559 node-v47-win32-ia32-Release.tar.gz
2017-04-18 12:52:17   28236559 node-v47-win32-ia32-Releasev140.tar.gz
2017-04-18 16:17:28   30914891 node-v47-win32-x64-Release.tar.gz
2017-04-18 12:51:53   30914891 node-v47-win32-x64-Releasev140.tar.gz
2017-04-18 13:15:13   29682735 node-v48-darwin-x64-Release.tar.gz
2017-04-18 13:05:23   37285125 node-v48-linux-x64-Debug.tar.gz
2017-04-18 13:04:53   31586824 node-v48-linux-x64-Release.tar.gz
2017-04-18 13:16:19   29682977 node-v51-darwin-x64-Release.tar.gz
2017-04-18 13:06:15   31587776 node-v51-linux-x64-Release.tar.gz

[springmeyer]

Thanks for flagging this problem @flippmoke. What happened is that:

• The --toolset option is what we use to request binaries be specifically versioned a custom path.
• This is used by modules like node-sqlite to provide binaries, by default for vs2013, and also binaries for vs2015 (--toolset=v140)
• node-mapnik is different: because it can only be compiled with vs2015 (due to c++11 usage), we only previously published --toolset=v140 binaries
• But node-mapnik is also different: the {toolset} variable was not used previously in the binary config in the package.json. So the v140 binaries are posted at the normal url (did not have a v140 in their path)
• This was intentional on my part to make the install default to the vs2015 binaries since no other options existed

The breakage is because I forgot about this subtlety when I added the {toolset} variable to node-mapnik v3.6.0 so that we could also publish Address Sanitizer binaries (asan).

I think the ideal solution is just as you've done: to provide binaries are both paths. If users do npm install --toolset=v140 (as many docs have) the vs2015 binaries should be used. If users don't pass this option, the same binaries should also be used. So, copying/duplicating binaries I think makes sense. So, the remaining step here is to automate it.

[springmeyer]

This is now fully avoided in #758. We no longer build these alternative binaries since we've been able to build node-mapnik now against the stock windows nodejs binaries. So the --toolset flag is no longer used to provide alternative windows binaries.