build with node-gyp #132

brianc opened this Issue Jun 7, 2012 · 14 comments


5 participants

brianc commented Jun 7, 2012

node-postgres needs to use node-gyp for builds to support v0.8


defunctzombie commented Jun 7, 2012

Is anyone actively using the bindings? Do they support things that the native js doesn't? And/or are they faster? I might have asked this in the past but figured I would bring it up again during the 0.8 migration window.


brianc commented Jun 7, 2012

I don't have usage statistics for who is using the bindings and who is using the pure javascript version. My aim was to have both the bindings and pure javascript support exactly the same things, but actually the javascript version has pulled slightly head (namely binary protocol). AFAIK The javascript bindings actually use the same protocol to communicate with the server as libpq. In my initial, trivial, worthless benchmarks the bindings were 2x as fast as pure javascript. My benchmark did not let the v8 "warm up" the javascript or anything a real benchmark should do. I do know "back in the day" (re: node v0.2.x days) some folks were requesting/complaining about javascript only client so I provided c bindings to libpq.

jacombs commented Jun 9, 2012

I spent far too much time in the past two weeks trying to get node-postgres to work with Heroku Postgres from a Windows client. Was not successful. Ultimately discovered that the problem was that:

  1. Heroku Postgres requires an SSL connection,
  2. node-postgres requires if you want to do SSL,
  3. node-postgres uses node-waf (no longer recommended) to compile with the bindings,
  4. node-waf does not work on Windows (my preferred development environment).

Because of this I've given up on using node-postgres. I'm looking at other options.


defunctzombie commented Jun 9, 2012

@jacombs is there a point to your comment? We know about these limitations and as @brianc notes in this report, the node-gyp (new way) is a TODO item. To say that node-waf is no longer recommended is great, however this doesn't mean projects magically get ported over. Maybe you could take a moment to create a gyp file for the project?

jacombs commented Jun 9, 2012

@shtylman Yeah I was answering your question. And I also gave some detail about the problems I was having. Last thing I expected was your rude, snotty response. Did I suggest anything about anything "magically" getting ported over. Oh and I've taken far more than a "moment" creating a gyp file. I spent days creating gyp files trying to get it to work without success. Please stop trying to stir up shit.


defunctzombie commented Jun 9, 2012

I wasn't trying to stir anything up :) To me your comment came across as just a list of grievances ending with nothing but an exclamation about how you no longer wanted to use the module (which doesn't inspire anyone to really help you further does it?)

Do you have the gyp files you created? They can be a starting point for this work.

mgutz commented Jun 9, 2012

@jacombs Have you considered running node in a Linux virtual machine? Some of my team prefer Windows as well. They run node in a VirtualBox guest and map a network drive via samba to edit and browse files in Windows.

jacombs commented Jun 9, 2012

I don't know what "grievances" you're referring to. I was simply trying to be clear about the problem. And I never said I "no longer wanted to use the module". Look, I wish I hadn't said "I've given up on using it", I didn't realize it would hurt anybody's feelings. I was just saying that I gave up on it and moved on. Because that is what I did.

I've done heavy C in the last 30 years but never C++. So I studied the node-gyp stuff and was successful in using it to build little "hello-world" type C++ bindings, and they worked fine. But when I tried to apply the same process to the pg source I consistently got "syntax errors" in this statement:

static void 
io_event(EV_P_ ev_io *w, int revents)
    TRACE("Received IO event");
    Connection *connection = static_cast<Connection*>(w->data);

As best I can remember, EV_P_ is being replaced at compile-time by an empty string, producing cascading syntax errors.

jacombs commented Jun 9, 2012

@mgutz Actually I do run Linux in a virtualbox (Linux Mint) and it works great. And in fact I was doing exactly what you were talking about with Samba and mapped drives. But I couldn't get the workflow down right, switching back and forth. I'm thinking I definitely need to revisit that though. That may be the best possible solution. Thanks.

booo added a commit to booo/node-postgres that referenced this issue Jun 10, 2012


brianc commented Jun 11, 2012


You can and should use the pure JavaScript bindings when you are working on windows. You can switch to use the native bindings on heroku when you deploy.

I seriously doubt Heroku is running the unstable v0.7.x branch of node so the node-waf build on Heroku should still be working for a while. I will have node-gyp in place before v0.8.x ships.

There is an old but unclosed issue requesting SSL support be added to the pure javascript bindings. It's on my list, though there are a few other things of higher priority.

I will be porting the project to use node-gyp asap. I will not however actively support a windows native build or ship one with the module using my own time. The beautiful thing of open source is it can be a collaborative community effort, and I'd happily work with someone else or incorporate changes which focus on windows native support.

I would recommend though to use the pure javascript bindings on windows and only switch to native mode if/when your production deployment requires it.

@booo Thanks for the pull request - I'll take a look at this ASAP. Had to work all weekend so I wasn't able to tend to it, but still many thanks.

jacombs commented Jun 11, 2012

@brianc I understand. Thank you for your response and for your hard work. I never realized that the existing file is linux-only. I thought it was a build problem or my lack of understand of node-gyp or C++. That explains why it refused to yield to my medieval coding techniques.


booo commented Jun 11, 2012

The commit is meant to serve as a starting point. Works on my specific linux/node (v0.6.12) setup. I think one should add more include paths or somehow auto detect the include right include paths. Not sure if this is possible at all.

What's the actual problem to support windows? Is there no windows code base for the postgres client library?

@brianc DON'T PANIC - There is enough time to implement new features...


brianc commented Jun 11, 2012

😄 no panic here!

There isn't really a problem supporting a native windows binding so much as I don't have the inclination to do so since I don't really use windows for c/c++ development. Libpg is mostly portable, but there are a few small gotchas I think.

Anyways, I'm gonna take a peek at your gyp file soon & test it out. Thanks again


@brianc brianc closed this in 9132075 Jun 19, 2012


brianc commented Jun 19, 2012

@booo thanks for your help! I modified your bindings.gyp file to support osx as well as linux. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment