Meta-issue to track cross-compiling progress

[vweevers]

As this effort spans multiple projects (both in tooling and target audience). In mostly chronological order:

• prebuildify
  • Allow overriding strip command (PR: allow overriding strip command for cross-compilation prebuild/prebuildify#19)
  • Allow overriding platform ([wip] Allow overriding target platform when cross-compiling prebuild/prebuildify#22) (PR: Cleanup options prebuild/prebuildify#26)
  • Add libc flavor and arm version to prebuild name (PR: New naming scheme prebuild/prebuildify#27)
• node-gyp-build
  • Support prebuilds for libc and arm flavors (PR: Optionally support prebuilds for libc and arm flavors prebuild/node-gyp-build#14)
  • Use new naming scheme (PR: New naming scheme prebuild/node-gyp-build#19)
• prebuildify-cross: feature complete? TBD using docker directly
• docker-images (PR: Update prebuild/docker-images#5)
• leveldown
  • Integrate prebuildify-cross: (PR: [wip] cross-compile prebuilds #572 Cross compile armv7 (for RPI) #584)
  • Upgrade above deps (PR: Update prebuildify and node-gyp-build #625)
    • Add --tag-armv flag in scripts/cross-compile (this ensures that e.g. armv6 machines don't select the armv7 prebuild)
    • Replace npx prebuildify -t 8.14.0 --napi --strip with npm run prebuild (now equal)
  • Determine which ARM flavors we actually need (discussion: Determine for which ARM flavors we want prebuilds #574)
  • Change Travis setup
    • Add cross-compiling to matrix (PR: Create explicit CI job matrix #585)
    • Don't pass -t electron@3.0.0 to prebuildify when cross-compiling

Feel free to edit if I missed anything.

cc @ralphtheninja @ahdinosaur @staltz @mafintosh

[ralphtheninja]

How do we pass ARM version suffix for output folder (e.g. -v7) to prebuildify?

The ARM_VERSION environment variable is passed on the docker container here https://github.com/ahdinosaur/prebuildify-cross/blob/master/build#L237 , so it's available to prebuildify when invoked here https://github.com/ahdinosaur/prebuildify-cross/blob/master/build-in-docker#L16

So we need to modify prebuildify to create this suffix for the arm case here https://github.com/mafintosh/prebuildify/blob/master/index.js#L33

Same question for libc flavor. Or should prebuildify always include it in output folder names?

I guess this should go into prebuildify in the same sense. If you think about it, prebuildify is used to make the binaries and node-gyp-build tries to resolve/load them, so it makes sense that they have similar/mirrored behavior (i.e. producer/consumer logic)

[vweevers]

Making our desired changes the default behavior (rather than optional features) of prebuildify and node-gyp-build would be the cleanest solution, yea. It probably means both will need a major bump.

[ahdinosaur]

• Don't pass -t electron@3.0.0 to prebuildify when cross-compiling

oh okay good to know. should i change the api of prebuildify-cross so that it takes arguments to pass to prebuildify? at the moment it just runs npm run prebuild, without any way to change arguments specifically for the prebuild.

i could change the prebuildify-cross api to something like:

prebuildify-cross --args="-t 8.14.0 --napi --strip" --platform=linux --arch=arm --arm-version=7

would that be helpful? if so, here's a branch for that functionality: https://github.com/ahdinosaur/prebuildify-cross/tree/prebuildify-args 🌟

(by the way, i will be away from my computer for next 5 days, off to party in the bush 🏞️ ☀️ 💃 🎶 )

[ralphtheninja]

Don't pass -t electron@3.0.0 to prebuildify when cross-compiling

@vweevers At first I was wondering why we shouldn't do this, but I guess it doesn't make any sense to do this for e.g. android, but maybe we want this for other flavors? Would it make sense to have prebuilts made for electron on say Raspberry PI?

would that be helpful?

@ahdinosaur Yes, I think this would be helpful, since we need to have different behavior for npm run prebuild depending on which targets we are building for.

[vweevers]

Status update: it has taken quite a few iterations (of PRs, test releases and discussions), but I think we finally have a complete plan now. Note that some of the discussion above is outdated as we decided to replace prebuildify-cross with our (prebuild's) own Docker images.

I've opened prebuild/prebuildify#26 which consolidates recent ad-hoc changes (for overriding strip, platform, arch) into a clean and documented set of options. Once that is merged, we'll have to update the Docker images accordingly. Then we can implement the new naming scheme for prebuilds (prebuild/prebuildify#25), on which the discussion has now settled as well.

The only thing that's unclear to me is Android support. Specifically, whether to use and target the nodejs-mobile forks of node and node-gyp. I'm not convinced that's the way to go, because I'm afraid we'll be stuck with it. Node core is open to improving Android support - so that's what I prefer to aim for. I don't see an easy way to support both.

[staltz]

@vweevers nodejs-mobile uses node chakracore because (for reasons I can't remember now but Janea systems documents it well) that makes it possible to run in iOS. Having leveldown supported in iOS is as important as Android support in my opinion. Node core isn't yet as developer friendly as nodejs-mobile is when targeting mobile.

[vweevers]

Would it be an option to use node core for Android, and nodejs-mobile for iOS? The former is already working. For the latter, I'm hoping that:

1. Telling prebuildify to use nodejs-mobile-gyp instead of node-gyp is enough to get prebuilds working, running in a MacOS job in Travis
2. os.platform() returns a distinct value (e.g. ios?) so that node-gyp-build can select the correct prebuild.

[vweevers]

nodejs-mobile uses node chakracore because (for reasons I can't remember now [..]) that makes it possible to run in iOS

Thanks to this tweet I learned it's because iOS disallows write-access to executable memory. V8 7.4 addresses this by introducing a interpreter-only mode. Some time in the future node core should be able to take advantage of that!

cc @mcollina Does node have any official plans yet?