add support for nng

[nullr0ute]

nng is the new upstream replacement to nanomsg https://github.com/nanomsg/nng

It would be useful to be able to use either the older nanomsg while providing a migration path to nng

[reqshark]

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

[snailuj]

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

[nickdesaulniers]

I think nng should be a different library than node-nanomsg. It's non trivial to write nodejs native libraries (C++), and you can't just swap them out. 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.

…

On Fri, Jan 11, 2019, 6:12 PM snailuj ***@***.*** wrote: 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 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#202 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvUX6z47-TvgJzKjZCKHs4MDbU2mvwgks5vCUR9gaJpZM4ZbbHO> .

[reqshark]

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