-
Notifications
You must be signed in to change notification settings - Fork 459
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
Provide definition files for stable API symbol exports #720
Comments
Hi @mjmacleod, |
Hi @mjmacleod, |
Thanks for the response. In terms of our specific use case (we are quite far from the normal I realise)
Our codebase compiles with clang for mac/ios and otherwise with gcc, and uses various features specific to these (including quite a bit of assembly) so isn't overly MSVC friendly. Also sticking to gcc/clang allows us to cross compile from a single linux build server that uses gitian for reproducable builds, all of which is also quite important to us. The source code is public, so I'm happy to share, however I do still have some pending changes I need to push - I just got the Windows/MinGW part of this working properly yesterday so am still busy cleaning various things up. Likely I'll be done by weekend so might be better for you to look at then: This script currently drives the electron build, it sets a few things up and then lets autotools do the rest https://github.com/Gulden/gulden-official/blob/2.2_development/developer-tools/build_node.sh |
Kind of, we already had a working NAN wrapper before, so at the time I was hoping to get NAN to work using MinGW, but could find very little info on it, I was hoping the people on that bug may have had some success with their problem which might in turn help me figure out how to get NAN working. After more digging though I realised though that updating to N-API/node-addon-api was going to be more sensible, and thanks to the stable C API the MinGW interoperability I was hoping for would actually be possible with N-API/node-addon-api. |
A rough approximation of available N-APIs can be obtained by running
The NAPI_EXTERN napi_status
napi_do_something_useful(...); |
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made. |
This is currently being discussed in: #855. @mjmacleod if you want to comment on the proposal there that would be great. |
There are cases where it is desirable to be able to compile a node extension without actually having node.exe present on the system, or in the case of compiling an extension under msys2 with mingw64 where it is not possible to link against node.exe directly anyway.
In these cases it is possible/desirable to instead work with a definition file containing the exported symbols instead, it is of course possible to generate this manually from node.exe (which is what I am doing now), and with a bit of fiddling maybe even automate the process (with the hassle of having to obtain the right node.exe to do so)
However it would be cleaner/better if the stable api symbol definitions were just provided as part of node-addon-api itself.
I provide a sample of the .def file I'm currently using.
node.def
The text was updated successfully, but these errors were encountered: