search

mapbox / windows-builds

DEPRECATED! build scripts for mapnik dependencies, mapnik, node-mapnik, node, libosmiom, osmium-tool
38 stars 22 forks source link

Build latest node (4.x ATM) #60

Open wilhelmberg opened 8 years ago

wilhelmberg commented 8 years ago

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

springmeyer commented 8 years ago

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

springmeyer commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 :white_check_mark: :white_check_mark:
4.2.0 :white_check_mark: :white_check_mark:
4.1.2 :white_check_mark: :white_check_mark:
4.1.1 :white_check_mark: :white_check_mark:
4.1.0 :white_check_mark: :white_check_mark:
4.0.0 :white_check_mark: :white_check_mark:
3.3.1 :white_check_mark: :white_check_mark:

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 node@4.2.1:

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 commented 8 years ago

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

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

springmeyer commented 8 years ago

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 commented 8 years ago

I suggest we don't support 3.3.1

:+1: Yes, lets target latest 4.x

wilhelmberg commented 8 years ago

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 node@4.2.1.

brianreavis commented 8 years ago

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 https://github.com/naturalatlas/node-gdal/issues/127 (naiive question... not really familiar w/electron)

wilhelmberg commented 8 years ago

@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, ...