Packaging sharp with nexe as painlessly as possible

Hey @lovell 😃

I’m currently using nexe to package a command line utility that has sharp as a dependency.

Since native modules cannot be integrated into the final executable, my build script copies sharp.node into a sub-directory next to the executable (“./sharp/”). It also generates an adapter that properly locates this copy of sharp.node from within the executable.

It works perfectly under windows. Of course, the build script has to copy the plethora of dlls that comes with sharp, but they’re simply put into the same directory as the copy of sharp.node.

However, in OSX, the .dylib files are (strangely) not in the same directory as sharp.node when sharp is built (but in a “cousin”-directory). So when I copy those files into the new sub-directory next to the packaged executable, I logically get an error about @rpath/somelib.number.dylib not being found.

So, I’m wondering…

• why the inconsistency between windows and OSX ? Can’t the dylibs be in the same directory as sharp.node, and be referenced from sharp.node as such, so that they could be copied/moved together more easily?
• should I expect the same issue with .dso files in linux?

I’d very much like not to have to recreate the whole node_modules hierarchy just to copy dynamic libraries if at all possible. Right now, the “copy the .node file together with dynamic libraries in the same directory” behavior is triggered by nexe itself while recursively exploring require statements (so I know for a fact a native module found that way actually is a runtime dependency and not a dev dependency). Also, I don’t have to worry about the “depth” of the dependency if I keep it flat (whether it’s in a node_module within a node_module within a node_module or not makes no difference whatsoever). I’m sure you get the idea.

Any help, pointer, workaround would be deeply appreciated.

Take care and thanks again for the herculean work you pull on sharp on a daily basis,

Julian

[jaubourg]

FYI I ended up reproducing the hierarchy (keeping only .dll and .node files) than pruning the build location. Not ideal but I can live with it. A compact, ready to incorporate, version would be cool.

Anyway, sorry for the late feedback 😉

[lovell]

@patrickhulce Hello, when npm install (and npm rebuild) are run, npm runs node-gyp with the binding.gyp config. It uses pkg-config to search for a globally-installed libvips. If not found, it will invoke the download_vips() function from binding.js to populate the vendor directory with the relevant libvips binaries for the detected platform.