Build latest node (4.x ATM)

[wilhelmberg]

Update build scripts here and https://github.com/mapbox/node-cpp11

@springmeyer What's your opinion on how to proceed?
https://github.com/mapbox/node has been forked from https://github.com/nodejs/node-v0.x-archive
which has been moved to https://github.com/nodejs/node

• new mapbox/node2 repo from https://github.com/nodejs/node ?
• delete existing mapbox/node and fork again from from https://github.com/nodejs/node ?

[springmeyer]

@BergWerkGIS seems like the first step(s), before trying to automate, are:

• Figure out what visual studio version the nodejs devs are using to compile the existing 4.x binaries
• If not VS 2015, then we'll need to continue building our own version
• Test building 4.x with vs 2015 locally, figure out if any patches are needed still (probably?)
• Provide those patches upstream
• Wait for a 4.x release with our patches for vs 2015

[springmeyer]

@BergWerkGIS I see @brianreavis getting ready for a node-gdal release that would support Node 4.x. Its not critical but would be nice to soon support VS 2015 Node 4.x builds. Let me know if you plan to look into the items above or whether I should take some time to do so.

[wilhelmberg]

Let me know if you plan to look into the items above or whether I should take some time to do so.

y, looking into it.

[wilhelmberg]

I changed the scripts to allow for compiles of node 0.x and >0.x.

These are the first results, directly from https://github.com/nodejs/node, only overriding /MT -> /MD` (no other changes):

version	x64	x86
4.2.1	✅	✅
4.2.0	✅	✅
4.1.2	✅	✅
4.1.1	✅	✅
4.1.0	✅	✅
4.0.0	✅	✅
3.3.1	✅	✅

I suggest we don't support 3.3.1 as it creates iojs.exe and in all our mapbox/node-* build- and AppVeyor-scripts, where we use the custom VS2015 node.exe we rely on that name.
I think it's not worth the effort to change all those for an interim version.

Next tests with [email protected]:

• node-mapnik
• node-gdal

I think we should investigate again, if node@MT and native modules node@MD really potentially have the same problems as mixing Debug/Release libs.
If not, we could again use the stock node.exe.

[wilhelmberg]

If not, we could again use the stock node.exe.

just looked at the stock binaries: seem to be built with VS2012.

[springmeyer]

just looked at the stock binaries: seem to be built with VS2012.

Okay, so we'll keep building our own for now.

I think we should investigate again, if node@MT and native modules node@MD really potentially have the same problems as mixing Debug/Release libs.

If we are building our own I think sticking with MD feels easy and safer. But yes, MT might work fine - we have no conclusive evidence it did not. TileMill always used the stock node with MT. However we know TileMill had some mysterious crashes/memory problems....

That said if you feel like 1) not-patching is cleaner and 2) you can comfortably assess and test at MT build and confirm it behaves the same and performs the same... I'm happy switching. What do you think?

[springmeyer]

I suggest we don't support 3.3.1

👍 Yes, lets target latest 4.x

[wilhelmberg]

I'm happy switching. What do you think?

Definitely worth a try.
Will do as soon as I've successfully built either node-mapnik or node-gdal with [email protected].

[brianreavis]

I suggest we don't support 3.3.1

Does this mean Electron won't be supported, or does this just mean pre-built binaries for it won't exist? Regarding naturalatlas/node-gdal#127 (naiive question... not really familiar w/electron)

[wilhelmberg]

@brianreavis Not familiar with electron either.
I guess I have to give electron a shot as soon as I've made node-gdal compile with node>0.x.
I'm ok with providing 3.3.1 binaries for this special node-gdal use case only, but I don't want to do it for all native modules we support: node-mapnik, node-sqlite, ...