fuwaneko / node-protobuf

Google Protocol Buffers wrapper for Node.js [UNMAINTAINED]
181 stars 42 forks source link

Trying to install with reference to non-default location for protocol buffers #58

Closed IanMeyers closed 8 years ago

IanMeyers commented 8 years ago

Hello,

I'm trying to install node-protobuf into my project with reference to a version of protocol buffers which is local to the project - aka not in the default location, because my app needs to be able to package up protocol buffers along with node-protobuf and my code.

$ PKG_CONFIG_PATH=lib/protobuf/lib/pkgconfig npm install node-protobuf
\
> node-protobuf@1.2.11 install /home/ec2-user/kpl-deagg/node_modules/node-protobuf
> node-gyp rebuild

make: Entering directory `/home/ec2-user/kpl-deagg/node_modules/node-protobuf/build'
  CXX(target) Release/obj.target/protobuf/src/init.o
In file included from ../src/init.cpp:1:0:
../src/common.h:11:45: fatal error: google/protobuf/dynamic_message.h: No such file or directory
 #include <google/protobuf/dynamic_message.h>
                                             ^
compilation terminated.
make: *** [Release/obj.target/protobuf/src/init.o] Error 1
make: Leaving directory `/home/ec2-user/kpl-deagg/node_modules/node-protobuf/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:267:23)
gyp ERR! stack     at ChildProcess.emit (events.js:98:17)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:810:12)
gyp ERR! System Linux 3.14.23-22.44.amzn1.x86_64
gyp ERR! command "node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/ec2-user/kpl-deagg/node_modules/node-protobuf
gyp ERR! node -v v0.10.32
gyp ERR! node-gyp -v v1.0.2
gyp ERR! not ok
npm ERR! Linux 3.14.23-22.44.amzn1.x86_64
npm ERR! argv "node" "/usr/local/bin/npm" "install" "node-protobuf"
npm ERR! node v0.10.32
npm ERR! npm  v2.6.1
npm ERR! code ELIFECYCLE

npm ERR! node-protobuf@1.2.11 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the node-protobuf@1.2.11 install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the node-protobuf package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls node-protobuf
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/ec2-user/kpl-deagg/npm-debug.log

Is this something that can be addressed? It looks like the path that it's trying to find google/protobuf/dynamic_message.h. This file is in $project/lib/protobuf/include/google/protobuf/dynamic_message.h. I can't tell if this is something due to protobuf or the npm installation of node-protobuf.

Thoughts?

fuwaneko commented 8 years ago

Try version from git. If it doesn't work, try to set LIBPROTOBUF environment variable directly instead of PKG_CONFIG_PATH.

sergiyvoytovych commented 8 years ago

try install this sudo apt-get install g++ protobuf-compiler protobuf-c-compiler libprotobuf-dev libv8-dev libgoogle-perftools-dev make libprotoc-dev default-jre libboost-dev

fuwaneko commented 8 years ago

@sergiyvoytovych it's clearly not what op wants. And most of what you propose to install is not required.

fuwaneko commented 8 years ago

@IanMeyers did it help?

IanMeyers commented 8 years ago

I was able to satisfy the compile time dependency with a local installation of protobuf, and then package the protobuf libs into the module with a local path reference. Unfortunately this approach isn't going to work for me due to the size of the packaged artefact (>70MB) so I am going to look at a pure JS implementation of protobuf.

That said, I still think it would be nice if the --pkgconfig could use a local path to protobuf.

fuwaneko commented 8 years ago

@IanMeyers latest version uses pkg-config. But yes, packaging binary modules is not the best idea.