-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for single-level module_path when packing #371
Conversation
Prior to 0.7.1, a module_path of `./lib` would result in a package containing files like this (using `test/app8` as an example): lib/app8.node The switch to tar 3 in 0.7.1 causes the same package to end up like this: package.json app8.cc binding.gyp index.js README.md lib/app8.node which causes a problem during remote binary installation: node-pre-gyp ERR! Pre-built binaries not installable for PACKAGE@0.0.1 and node@8.3.0 (node-v57 ABI, glibc) (falling back to source compile with node-gyp) node-pre-gyp ERR! Hit error ENOTDIR: Cannot cd into '..dirs/package/lib' This commit fixes this problem and allows for single-level module_path values.
@allenluce thank you for this. Looks like there are some minor failures (https://travis-ci.org/mapbox/node-pre-gyp/jobs/371702547#L805) when this test is run on different operating systems. How about, instead of checking actual file names, we just check the # of files added? |
But don't compare Linux to Apple.
I always seem to forget this bit! Let me know if the last commit will do it for you. |
This should work everywhere except AIX.
ea7a374
to
68f907f
Compare
This is based on what showed up during an Appveyor run. Someone with more Win32 module building experience should verify that these are expected and correct.
68f907f
to
6801a8b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great @allanwalkerit - thank you so much! Per discussion with @springmeyer plan is to release a new version today. The retire failures have been removed in master, so we can go ahead without those.
Next attempt at fixing the installation error. This time with merged PR mapbox/node-pre-gyp#371
With the merge of mapbox/node-pre-gyp#371, node-pre-gyp version 10 now works again. Also grab the new mocha, just because.
With the merge of mapbox/node-pre-gyp#371, node-pre-gyp version 10 now works again. Also grab the new mocha, just because.
* Allow for single-level module_path when packing Prior to 0.7.1, a module_path of `./lib` would result in a package containing files like this (using `test/app8` as an example): lib/app8.node The switch to tar 3 in 0.7.1 causes the same package to end up like this: package.json app8.cc binding.gyp index.js README.md lib/app8.node which causes a problem during remote binary installation: node-pre-gyp ERR! Pre-built binaries not installable for PACKAGE@0.0.1 and node@8.3.0 (node-v57 ABI, glibc) (falling back to source compile with node-gyp) node-pre-gyp ERR! Hit error ENOTDIR: Cannot cd into '..dirs/package/lib' This commit fixes this problem and allows for single-level module_path values. * Compare apples to apples But don't compare Linux to Apple. * Use a platform-specific dynamic object extension This should work everywhere except AIX. * Fix Win32 file expectations This is based on what showed up during an Appveyor run. Someone with more Win32 module building experience should verify that these are expected and correct.
Prior to 0.7.1, a module_path of
./lib
would result in a package containing files like this (usingtest/app8
as an example):The switch to tar 3 in 0.7.1 causes the same package to end up like this:
which causes a problem during remote binary installation:
This commit fixes this problem and allows for single-level module_path values.
Fixes #364