search

Rantanen / node-mumble

Mumble client in Node.js
MIT License
155 stars 48 forks source link

Prebuild binaries and electron support #41

Closed justinmchase closed 9 years ago

justinmchase commented 9 years ago

I pre-apologize for the length of this issue :)

I have been investigating the use of this package for consumption in an electron application as a mumble client, using browser audio apis to capture and play audio. I have managed to get a working prototype but not without jumping a few hurdles first.

I wanted to first coordinate with you to discuss some of the problems I encountered and also to gauge your interest in the sort of pull requests I may be able to offer.

The main problem is that simply doing: npm install mumble failed for me, seemingly because I am using iojs v2.3.0. Specifically, each of the native packages it depends on fail to build successfully (we tried windows and osx). Interestingly enough, however I was able to clone them each from github and build them from source directly without any problems. So I'm not sure what the problem is but there appears to be a difference between what is currently in NPM and what is currently in source.

One problem is simply that protobuf@0.11.0 does not support iojs:

npm WARN engine protobuf@0.11.0: wanted: {"node":">= 0.8.0 < 0.12"} (current: {"node":"2.3.0","npm":"2.11.1"})

To solve that I removed the dependency on protobuf and swapped it out with protobufjs, which is a pure JS implementation of protobuf, no native code or modules needed. This required some pretty trivial code changes, nothing major at all.

Next I built each of the native modules one at a time and linked everything together via npm-link. After that I created a simple electron application that uses the code to connect to my server and play audio via browser apis, which finally worked.

The only remaining issue is that in order for this to work in electron for actual users, the modules need to be pre-built (e.g. node-pre-gyp), since users will not necessarily have compilers on their systems.

Therefore, my current plan of action is to fork the following projects:

The latter 3, I simply want to convert into node-pre-gyp projects, compile against electron and upload the binaries to amazon.

As for node-mumble I want to:

My question to you is, to what degree are you interested in pull requests for any of this work? Also, how do you feel about me forking for these purposes? The changes in question here are largely superficial, nothing core to the logic of the modules is really changed just platform and compatibility related stuff.

And finally, thank you for doing this work openly already. It has been immensely helpful.

Rantanen commented 9 years ago

Short answer to the question: I'm interested in any pull requests that make it easier for people to use the library (for any purposes, including node-pre-gyp or maintaining a fork for it) without breaking the existing use cases (namely the normal npm install in this case).

So go ahead and fork whatever you want :)

protobufjs

I'm definitely interested in the protobufjs change as the protobuf is abandoned if I remember right. It happens to work for now so I haven't been motivated to touch it. If you've already done the changes, please go ahead and send a pull request. :)

node-pre-gyp

For node-pre-gyp I'd need to look into it more. The big question here is that can the node-pre-gyp changes be done in such a way that the project can still be published to npm and consumed normally without too much trouble.

So if we can have:

This should be enough to allow normal npm install to work by building the stuff from the source while allowing publish-time scripts to run the node-pre-gyp build.

justinmchase commented 9 years ago

Great, thanks for the reply.

I will work on getting the protobufjs patch for you, I do have a working version of that locally. I also will have a few config.h files in the various sub projects for win/x86 & linux/x86 that are pretty straight forward.

The node-pre-gyp work may be a little trickier. I have been running into numerous bugs in its support for newer versions of electron, as well as the electron-rebuild project not working the way I need it to. I've created a project electron-updater-tools which resolve the various issues and allow us to make binaries compatible with the electron-updater we are using.

I'm going to try to submit patches back to node-gyp and node-pre-gyp if applicable, or figure out what I'm doing wrong. But for now I'm going to have to use the custom scripts. Without going into too much detail the bugs I am hitting are:

I have nearly completed the conversion of the electron-celt project, if you want to see what I've done so far.

The changes are specifically in:

Binaries are uploaded to s3 at urls like: https://s3.amazonaws.com/evolve-bin/electron-celt/electron-celt-0.1.7-win32-x64-release-master.tgz

Working on osx builds in travis next.

Flet commented 9 years ago

Some interesting recent discussion on native modules:

On Maintaining a Native Node Module

We Need An Automated Module Build System

justinmchase commented 9 years ago

Good links @Flet

I concur with all of those problems. I solved it with my own set of scripts. You can try getting electron-mumble. If you do npm install it should pull down binaries like node-pre-gyp would but the binaries are compatible with iojs or electron without needing recompilation.

I have a pull request out to node-gyp to support electron with their delay load technique inherently but node-pre-gyp seems to have some problem I don't understand still. Working on it.