On Friday, February 10, 2012 5:26:34 PM UTC-5, TooTallNate wrote: > > On Fri, Feb 10, 2012 at 12:35 PM, Roman Shtylman <[email protected]>wrote: > >> I think you guys are reinventing the wheel here with respect to building >> addons. Gyp and CMake were create specifically so you don't need to roll >> your own system. Maybe it is just me but I liked the fact that node-waf >> came bundled with the node install. This meant that I didn't have to go >> fetch any additional packages or items to build the addon. > > > I don't really see your concern here. We're attempting to do the same > thing with gyp as we did with waf, by providing a light wrapper around its > basic usage to help simplify the necessary gyp file module devs need to > create (same as the wscript file before). The only difference so far is > that instead of being bundled with node, you have to `npm install -g > node-gyp` to get it. As isaacs said at the beginning of this thread, we > only want more advanced/comfortable users compiling, so once new users are > ready, they can install node-gyp. While they're still new, they can rely on > precompiled binaries (same situation with the precompiled binaries > officially offered for node: I don't use them since I'm "advanced", but > they're wonderful for new user adoption). >
My main point was that by shipping it you don't make it harder for new people to use node, but by not shipping it you do make it harder for module creators to get started or tweak things. I always found that making modules is more of a "built in" process that is highly coupled with the release of node (especially given how all the tools are node specific). I also like the idea that if I don't want to use npm, I don't have to. Now if you make the tool downloadable through npm you end up having to use npm to start developing modules. I like lower barrier to entry :) > > >> I will also add that I am against shipping binary addons. The number of >> "parameters" you could be pivoting on is too great imho. If someone has a >> system in place to deploy binaries (deb, rpm, etc) I would think they >> should use that. Otherwise compiling these small addons for deployment is >> not that big a deal is it? I would be hesitant on a binary solution until >> someone can prove to me anyone would actually care to use it in a >> meaningful way. Right now, I just always build when I deploy and that works >> fine. The benefit here is that build time failure is much preferred to run >> time failure. >> > > The way I see it, nobody is forcing you to use any precompiled binaries. > There is always still the source code and installing node-gyp is a one-line > command, so just like node itself, more advanced users are probably going > to stick with compiling their native addons themselves, which is perfectly > fine in my opinion. npm could even offer a flag where it would compile > locally on the 'install' phase instead of downloading a precompiled binary, > much like the node-waf situation now. > > As said in the last paragraph, these precompiled binaries will mostly be > for the benefit of new users (especially Windows users) where they may not > even have a compilation toolchain installed (also especially true for OS X > users who rely on the installer, and don't have XCode installed). But for a > more advanced user like yourself, the only change in your workflow will > probably be invoking node-gyp instead of node-waf at build-time. > I suppose statically linking all the binaries will get around many of such concerns. Do consider that npm does not interface with the system's package manager (if it has one) and so the static linking may be the only sane approach.
