Add possibility to build against system SWORD library

[tobias-klein]

With these changes it's now possible to build against the system SWORD library by defining the environment variable LINK_SYSTEM_SWORD=1 before calling npm install.

[alerque]

I'm trying to "test" this by setting up actual distro packaging for it. I'm having trouble figuring out where to even start. The npm script 'build' just fires off 'node-gyp rebuild', but I don't understand why this would be 'rebuild' instead of 'build'. Rebuild assumes there is a bunch of stuff done already. A little experimenting and node-gyp build doesn't get too far either, it assumes there is a makefile and who knows what else that there isn't.

Given the scenario where I don't want any of the SWORD stuff to build (and won't have dependencies on cmake/git/curl/etc.) what entry point should I even be using to build & install this?

[tobias-klein]

Given the scenario where I don't want any of the SWORD stuff to build (and won't have dependencies on cmake/git/curl/etc.) what entry point should I even be using to build & install this?

After cloning the repo (and switching to the system-sword branch for now):

1. export LINK_SYSTEM_SWORD=1
2. Run npm install to install all dependencies (node-addon-api and node-gyp) and then build

After I checked this just now once more I fixed an issue with the include paths in case of the new "link system sword" scenario.

[alerque]

Aha, 971d816 is much better! I'll let you know if it pulls together here.

[alerque]

I think something might still be missing, the build does seem to be generating the needed artifacts, but they aren't getting installed. I'm installing to a fake chroot, but ending up with an empty structure:

npm install -g --user root --prefix "/path/to/chroot"

Pretty much all I get out of that is an empty folder lib/node_modules/node-sword-interface.

In build/Release/obj.target there is stuff that looks like the files that need to be installed, but I can't figure out how to make them end up where they belong.

[tobias-klein]

So far I've never used npm install to install to the system directories ... what's your actual use case here?

[alerque]

what's your actual use case here?

I'm "installing" to what is otherwise an empty directory as if it was the system root, then that directory gets tar'ed up and packaged as a distro package. This is the standard way of handling the creation of packages on most distros.

I tried npm install -u as well to do an install to my user directory but nothing is ending up in ~/.npm either.

[tobias-klein]

I see, ok. It would be interesting to see how other node module projects handle this usecase. In general, if an application depends on a package like node-sword-interface the easiest way to resolve this is to handle it via npmjs.com and then package the resulting application (like Ezra Project). I will read up a bit more on this usecase and see whether I can find some more information.

[alerque]

Ug, this has to do with npm wonkyness. It works when I tar up the resulting release (i.e. it would work from npmjs) but when npm install runs from a project directory (as I'm doing to test this PR) it only installs symlinks back to the current project directory!

The old behavior where this was possible seems to have been removed in NPM 5. It looks like alternatives for local testing of building packages are install-local (no comment on having to have a package to install a package) or using npm pack then npm install the tarball.

[alerque]

Your force push just now seems to have obliterated the just-posted include path fix using pkg-config.

[tobias-klein]

Your force push just now seems to have obliterated the just-posted include path fix using pkg-config.

I was using a different variant of the pkg-config line first and corrected it afterwards to the one suggested by you!

[alerque]

@tobias-klein Actually your version looked better to me. Neither is likely to be a problem but yours was more explicit which is usually a good thing.

I was actually kind of surprised pkg-config couldn't be coerced into just outputting the plain path on its own. It made me wonder if maybe the other side –the way you handle it in the app– isn't the side that should be adjusted, but I'm not familiar with building electron stuff either so maybe it can't handle cflags style values.