-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
src: kickstart addon by calling its constructor #20114
Conversation
I'll add the documentation if this modification is accepted. |
@nodejs/addon-api |
Couldn't you simply emit multiple I assume the goal is to be automatically forward-compatible but that's not necessarily a good idea. For starters, it cements the layout of That said... that ship may have sailed already because |
@bnoordhuis I don't understand why this particular PR would cement This PR makes no assumption about which Node.js function the addon calls, nor about the structure of the data it passes to that function. For N-API purposes, I don't know that it would help that I scanned over a range of
but since all these symbols take V8 objects, we can only call one such symbol, and only in such a way as is compatible with the current V8 ABI. So, scanning over a range of symbols would only make sense if we controlled the signature of those symbols. I think the lowest common denominator, as with the library constructor, is |
Wait a sec - this short-circuits the search for the version-specific init special symbol. I need to fix that. |
Like, what if the module self-registers, but with the wrong version? It should still look for the version-specific Init. |
It links a Since there is no version number to sanity-check on when |
@bnoordhuis this PR doesn't add the module to the linked list. It merely invokes the library constructor the second time around. Can we not retain the old structure for the case where Whatever problems there are with the addon loading we will have whether or not this PR lands, and AFAICT this PR doesn't add to them. |
If the addon does not self-register and a well-known Init symbol cannot be found, look for a version-agnostic symbol which calls the library constructor and call it if found.
21d4a1c
to
6740cdf
Compare
No, that's pinning us down for all eternity. Early Node.js releases were unversioned but we explicitly moved away from that because it's untenable in the long run.
It adds a second API that exploits what is essentially an oversight. It'll make it twice as hard to fix in the future. |
@bnoordhuis I've tried a different tack. Let's see where that leads us. |
If the addon does not self-register and a well-known Init symbol cannot
be found, look for a version-agnostic symbol which calls the library
constructor and call it if found.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes