Support dynamic linking of libnanomsg about node-nanomsg HOT 20 CLOSED

I would suggest submitting a PR to make this happen. https://github.com/brianc/node-postgres/blob/master/binding.gyp or https://github.com/nonolith/node-usb/blob/master/binding.gyp are good examples of gyp files that rely on system installations and still work across Windows, OS X, and Linux.

from node-nanomsg.

+1 for this

from node-nanomsg.

It's difficult to support dynamic linking on systems without a standard pkg-config, i.e. Windows.

from node-nanomsg.

Meanwhile, on POSIX systems it's as easy as going like this in binding.gyp:

{
  'targets': [
    {
      'target_name' : 'nanomsg',
      'include_dirs': [ '<!(node -e "require(\'nan\')")' ],
      'sources': [ 'lib/nanomsg.cc' ],
      'libraries': [ '-lnanomsg' ]
    }
  ]
}

from node-nanomsg.

the library suffers because of windows -_-

from node-nanomsg.

haha 👍

from node-nanomsg.

somehow related to this: I see there is a newer version of nanomsg lib (0.6), and node-nanomsg uses a fork of ver 0.5. Is there a roadmap for upgrading to the latest lib? I guess it would not be safe to try to build against the latest...

from node-nanomsg.

@sirudog good point, and definitely related.. we need to update the build to v0.6

from node-nanomsg.

Hi,

First of all, thanks for the quick response to my question of upgrading to 0.6!

I see you already gave a direction how to do this for POSIX systems, but would it be a lot of work to offer the dynamic linking support as sorenriise originally asked for?
For non-windows users it would be very helpful. I am also in the same situation as he was, and it would be nice if I did not have to do this change manually every time this lib is upgraded to a newer version of nanomsg c++ lib. I see the benefit of doing this c++ lib build step behind the scenes (for small isolated projects), but when you have a larger system where you want to control the versions of the libs for many language bindings, doing the c++ lib build yourself once, and linking to that from everywhere is the only way to go.

For example, in ZeroMQ node binding(https://github.com/JustinTulloss/zeromq.node), the installation of the zmq c++ lib is completely decoupled on POSIX systems, and for windows it is optional:
"Installing the ZeroMQ library is optional and not required on Windows. We recommend running npm install and node executable commands from a github for windows shell or similar environment.

installing on Unix/POSIX (and osx):
First install pkg-config and the ZeroMQ library.
This module is compatible with ZeroMQ versions 2, 3 and 4."

To my opinion the same installation strategy would be useful and more flexible for nanomsg users, too.
What do you think?

from node-nanomsg.

the same installation strategy [as zeromq] would be useful and more flexible for nanomsg users

I tend to agree. But the tradeoff here is that people will have trouble installing if we did that, which might limit access to the library. Maybe we could counter that likely effect with good install documentation. People have submitted tons of issues about how hard it is to install zmq.

The benefit of the current method is that we build an ad-hoc statically compiled binary linked to node.js. This means you can do npm install nanomsg on systems with only Node.js and it just works.

from node-nanomsg.

I understand that. Based on the previous comments (mainly the one by @tcr), what if I would change the build scripts (mainly binding.gyp) to introduce an option: use_system_libnanomsg = 'false'. (by default false = same way of installing as it is now)
So npm install nanomsg would still work.
If folks like me would like to link against the already installed libnanomsg, would need to change this line like npm install nanomsg --use_system_libnanomsg=true
Of course, this option would have an OS condition, set to Linux (where pkg-config does the job easily)
I can make a PR easily if you consider this a viable enhancement of the build process.
What do you think?

from node-nanomsg.

I can make a PR easily if you consider this a viable enhancement of the build process.
What do you think?

I think that would be worthwhile. While maintaining Windows support is important, I'm not too worried if this specific feature only works on OSX/Linux. While we don't have pkg-config on OSX, I would expect anything from /usr/lib or /usr/local/lib to be pulled in.

from node-nanomsg.

Go to the zmq module and look at how many "can't install" issues there are. You want that here?

Also I use pkg-config on OS X.

I am in favor the PR as long as regular installs are unaffected.

from node-nanomsg.

passing an option like --use_system_libnanomsg=true would be great during development and debugging on the C/C++ lib, since we wouldn't have to wait for libnanomsg to compile!

I'm going to say +1

from node-nanomsg.

You want that here?

No. But I think if we maintain our defaults, and add additional functionality that power users can opt into if they know what they're doing is ok, and helps us avoid the zmq issues.

from node-nanomsg.

OK, here is the PR #134

from node-nanomsg.

Build 221 (https://travis-ci.org/nickdesaulniers/node-nanomsg/jobs/87636715) seems OK, but I had a timeout issue in web sockets tests on node v0.10 (ws socket bus). I have found this issue #110, which seems related.
Well, at the moment, Travis CI builds only verify if the default installation works... but based on my changes in README.md (Test section), the dynamically linking scenario can also be verified, locally.

from node-nanomsg.

nice work @sirudog!

from node-nanomsg.

closed in #134 good job! 🚀

from node-nanomsg.

published in 2.1.5

from node-nanomsg.