Hi, I've written a small module that attempts to solve #2 and #3, called > node-bindings: https://github.com/TooTallNate/node-bindings >
I think this is a very good start. Apart from anything else, it defines a convention for a specific location of the bindings that's independent of the build tool. Already we have lots of modules that are looking in a series of locations (./out/Release/, ./out/default/ etc) and this will only get worse when we have gyp as well which builds by default to some other place like ./build/Default/. One thing it does do is impose the requirement to wrap every native addon with a js script, even if the API is completely implemented in the native library; there's no portable way to just drop the .node into the node_modules directory and have it located by module.js. I don't know how big an issue this is, but it needlessly creates a v8::Context. (There's a simple enough, bug ugly, way to deal with this by adding a variant-specific extension, eg Module._extensions['.win32.ia32.node'] = ... But I agree we should look first for solutions that don't hard-code these kinds of things into the core.) There is no stable C++ ABI, so you will also have to add the compiler > version as another argument to that list of targets. Some compilers do try > to do versioning with mapfiles, but it is rarely used. The worst thing that > can happen is having a version of node built with one version of a compiler > and an addon with another. The build tool would need to use the ABI that was used to build the node that's installed; not just guess based on the host platform, and that ABI (with all of the toolchain parameters that implies) would need to be fixed from the time of the first release of a new minor version for each platform. I think that's a realistic aim for the stable (ie even minor version) releases but is liable to break for the unstable ones. Although I like the idea of the addon SDK being separate (eg as with node and node-dev packages), you do guarantee they are aligned if they are the same installable entity. It's all too easy on a debian system to install a new xxx package, only to find that you then can't install the corresponding xxx-dev since some of its dependencies are not stable, or upgrading those breaks something else, or whatever. Thanks - Paddy -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
