Skip to content
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

Why does prebuildify have its own headers and node.lib cache? #64

Open
CMCDragonkai opened this issue May 12, 2022 · 5 comments
Open

Why does prebuildify have its own headers and node.lib cache? #64

CMCDragonkai opened this issue May 12, 2022 · 5 comments

Comments

@CMCDragonkai
Copy link

CMCDragonkai commented May 12, 2022

I've been trying out prebuildify on Windows, and I noticed it has its own node headers and node.lib cache.

For example:

C:\Users\Roger Qiu\AppData\Local\node-gyp\Cache\16.14.2

Is the node-gyp cache. While

C:\Users\Roger Qiu\AppData\Local\Temp\prebuildify\node\16.14.2

Is prebuildify's node cache.

Considering that many packages are using node-gyp-install as their install script, their cache is likely populated by node-gyp automatically, why is prebuildify then creating its own cache?

I also noticed that node-gyp will automatically fill the target with the current node version. But prebuildify doesn't. Even when node-gyp was using 16.14.2, prebuildify defaulted to 18.0.0, I had to explicitly set the --target=16.14.2 when using prebuildify to ensure it was using the same.

Furthermore on Linux, once I have nodedir set, prebuildify doesn't put anything in /tmp/prebuildify, it only does it on Windows.

@vweevers
Copy link
Member

prebuildify/index.js

Lines 183 to 187 in c6e4368

// Since electron and node are reusing the versions now (fx 6.0.0) and
// node-gyp only uses the version to store the dev files, they have started
// clashing. To work around this we explicitly set devdir to tmpdir/runtime(/target)
const cache = opts.cache || path.join(os.tmpdir(), 'prebuildify')
args.push('--devdir=' + path.join(cache, runtime))

@CMCDragonkai
Copy link
Author

I see, what about the need to explicitly set the --target in prebuildify that seems inconsistent with how node-gyp automatically knows the right version.

@vweevers
Copy link
Member

I see, what about the need to explicitly set the --target in prebuildify that seems inconsistent with how node-gyp automatically knows the right version.

prebuildify is geared towards Node-API, so the version of the executing node process is not necessarily the right version. It defaults to compiling against the latest node version (relying on backwards compatibility of Node-API, assuming that NAPI_VERSION is defined appropriately). You can also choose to compile against the minimum node version (relying on forwards compatibility, and not necessarily having to define NAPI_VERSION).

I don't know if there's a practical difference between these options though (because Node-API has delivered on their promise of compatibility, and defining NAPI_VERSION is a best practice in any case). It might just be that there is no good default for prebuildify, or better said, from a "glass half full" perspective, that any of these options would work as a default for the majority of users.

Furthermore on Linux, once I have nodedir set, prebuildify doesn't put anything in /tmp/prebuildify, it only does it on Windows.

The Linux behavior is as expected because setting nodedir tells node-gyp to use your own node source code instead of downloading headers from an official node version. How/where are you setting nodedir on Windows?

@CMCDragonkai
Copy link
Author

I wasn't setting nodedir on windows. Maybe that's the reason?

Windows nodejs installation by default doesn't come with headers.

So it seems it requires headers and also this thing called node.lib. Not sure what that is.

@vweevers
Copy link
Member

I wasn't setting nodedir on windows. Maybe that's the reason?

Yeah, that's it.

It shouldn't be necessary to set nodedir unless you want to build against a fork of node (or a specific commit of node).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants