> npm seems to handle this just fine for both JS and native (c++) node modules via gyp
Could you describe this in a bit more detail? Does gyp (in the context of npm) build the binaries at install time, or is it a repository of a bunch of pre-built artifacts?
In my experience of installing npm packages, it doesn't seem like it's building native extensions at install time, but it's hard to say for sure.
It does build them on install time, if a suitable compiler is available. A classic example is the `ws` module (WebSockets), when you install that you'll normally see the build log for its native dependencies on the npm output:
$ npm install ws
> [email protected] install /Users/coreh/Projects/test/node_modules/bufferutil
> node-gyp rebuild
CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
SOLINK_MODULE(target) Release/bufferutil.node
> [email protected] install /Users/coreh/Projects/test/node_modules/utf-8-validate
> node-gyp rebuild
CXX(target) Release/obj.target/validation/src/validation.o
SOLINK_MODULE(target) Release/validation.node
/Users/coreh/Projects/test
└─┬ [email protected]
├─┬ [email protected]
│ ├── [email protected]
│ └── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]It depends. Someone more experienced may be able to add more info, but gyp appears to know what is available pre-built vs what needs to be built. Depending on what platform and options you've selected it might call (for example) the Visual Studio C compiler to build a native extension for you.
Binary modules are usually built at install time.
> there's no reason similar conventions can't be created for C/C++ modules
"Oh, that's cute, you want me to do that instead of work on my project?"
There's a huge first-mover disadvantage to this that has to be solved.
npm seems to handle this just fine for both JS and native (c++) node modules via gyp, and it's officially supported on at least three platforms (Windows, Linux, OS X) using 3 different compilers AFAIK (microsoft c/c++, gcc and clang respectively). Granted, node enforces specific conventions for packaging and lookup (package.json and node_modules), but there's no reason similar conventions can't be created for C/C++ modules, even if they're more complicated due to language specific complexity (dynamic vs static linking). Mantaining packages up to date for a lot of open source projects could be done by a sufficiently dedicated community.