add support for nng about node-nanomsg HOT 4 CLOSED

totally agree.

NNG is implemented in C, requiring only C99 and CMake to build

so user would need to have a CMAKE to build it

and i wonder if there's a nice way to do an npm install with a cmake process

@nickdesaulniers, are you aware of anything like that?

@nullr0ute, we're building libnanomsg in the old school autoconf style but skipping ./configure by kind of doing from that from gyp... which is not exactly intuitive. so instead of cmake we've managed to bake ./configure script into node's gyp toolchain and just using that to pass compiler flags

just based on how hard that whole thing is to get right, i would imagine an npm-cmake would be better

from node-nanomsg.

I don't know enough about the build process to comment, but nng has API compatibility with nanomsg as one of its core aims, so once the cmake change is made there may only be a few changes required to the node-nanomsg C++ files.

Today nng offers this. You can relink an existing nanomsg binary against libnng instead of libnn, and it usually Just Works™. Source compatibility is almost as easy, although the application code needs to be modified to use different header files. I am considering changing the include file in the future so that it matches exactly the nanomsg include path, so that only a compiler flag change would be needed.
https://nanomsg.github.io/nng/RATIONALE.html

from node-nanomsg.

from node-nanomsg.

I think nng should be a different library than node-nanomsg.

after looking into NNG a bit more I agree with Nick, we can close this issue/question

problem 1

Nng may be api compatible, but I'll bet it's not abi compatible, so it's not like it's a drop in replacement for us.

a lot of new api plus clearly something there to preserve our current libnanomsg operations:

// This file supplies the legacy compatibility API.  Applications should
// avoid using these if at all possible, and instead use the new style APIs.

https://github.com/nanomsg/nng/blob/master/src/compat/nanomsg/nn.c

Not the real issue! Interface compatibility is like the last hurdle to an nng integration w/ nodejs

problem 2

this is our real issue and the basis for separating a node-nng module into a different binding

we have the nontrivial prerequisite to build and compile nng as C/C++11 binaries for direct execution from the node.js runtimes. nng uses a totally different build process than the versions of libnanomsg we're building for nodejs

from node-nanomsg.