make build tool independent

[juliangruber]

no need to be limited to node-gyp :) I came up with this because a project I want to use this on uses cmake-js.

I tested this in https://github.com/voltraco/node-taglib2 so far, but it should work everywhere as node-gyp reads all its config also from the environment variables npm sets.

[juliangruber]

This PR goes hand in hand with prebuild/node-gyp-build#4.

[mafintosh]

Very cool. Did you test that this works on windows?

[juliangruber]

not yet, will do

[mafintosh]

I don't see anything that wouldnt work but you never know ... windows

[juliangruber]

I tested this with taglib2 and it works :)

[bcomnes]

@juliangruber So in order to use this, you would land this patch and run https://github.com/juliangruber/prebuildify-load ?

[vweevers]

@bcomnes That is outdated by now. We can instead add the missing functionality to node-gyp-build, provided that it doesn't need new dependencies.

[bcomnes]

Sounds good

[vweevers]

Maybe a package rename is in order, but we can table that for now.

PR(s) welcome!

[bcomnes]

Don't quite have a vision of what you mean, maybe if we write it up?

[vweevers]

To clarify, I thought it was okay to add functionality to the existing modules and that we could later choose to rename node-gyp-build to something more generic.

But on second thought, there's a fundamental difference between prebuildify-load and node-gyp-build that may in fact warrant the existence of prebuildify-load (which has a better name too). While node-gyp-build wraps node-gyp, prebuildify-load externalizes that. Compare:

"scripts": {
  "install": "node-gyp-build"
}

"scripts": {
  "install": "prebuildify-load || node-gyp build"
}

The latter approach avoids needing integration code specific to e.g. cmake-js.

If we can agree (@mafintosh @ralphtheninja) that this is the preferred approach, we could move prebuildify-load into the prebuild org and revive it, phasing out node-gyp-build.

[mafintosh]

node-gyp-build is the only production dep needed to run the prebuildify stack, so we need to keep that extremely light (all the install speed comes from that package having no deps), so adding cmake there is prob a nogo. Making a new package for that use-case is fine

[vweevers]

@mafintosh My point was, with the approach of prebuildify-load, there's no need to add cmake.

[bcomnes]

I don’t personally have a need or a valid perspective on this so I’ll abstain

[mafintosh]

Old issue, but I think this makes sense actually. @vweevers should we revisit this?

[vweevers]

It's a good feature and doesn't add complexity. I'm for it, as long as it's semver-major because it will break prebuildify-cross.

[mafintosh]

@vweevers i just registered the @prebuild org on npm (you should have gotten an invite). Then we could make a prebuild loader tool at @prebuild/load (i see julian's is archived)

[juliangruber]

we could revive mine as well, I'm open to hand anything over

[vweevers]

Can we consider npm run install instead of npm install? The latter will slow builds down (doing unnecessary work), especially with prebuildify-cross

[vweevers]

Might need to add --build-from-source, if the install script is node-gyp-build.

[aminya]

@juliangruber Could you register your fork on npm so we can use it?

This fixes #49

[juliangruber]

@juliangruber Could you register your fork on npm so we can use it?

You can also publish it :) Or use the npm github syntax