Provide definition files for stable API symbol exports

[mjmacleod]

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

[NickNaso]

Hi @mjmacleod,
I don't know if we should export the symbols definition from node-addon-api because they are the symbol exported by the C api of N-API that is exported from the core.
I'm interested in the workflow and tools you used to build the native addon under msys2 with mingw64. Do you have some public code?

[NickNaso]

Hi @mjmacleod,
Is the following issue correlated with your work?
cmake-js/cmake-js#200

[mjmacleod]

Thanks for the response.
I also wasn't 100% sure technically where this bug belongs, you are of course right that theoretically the symbols are N-API which node-addon-api instead wraps, it would certainly be helpful to have the list of symbols provided somewhere though, its not overly important where.

In terms of our specific use case (we are quite far from the normal I realise)

1. Our software currently compiles both to a daemon as well as a GUI app with GUI written in Qt (windows/mac/linux)
2. Further it compiles into a library (more of a framework really in terms of functionality) with JNI bindings (which are used in an android app that handles the UI and lets the framework do the rest)
3. As well as a library with obj bindings (that are used in an iOS app - similar to android app)
4. The latest target is to build both a node and electron module (practically the same thing now of course) so that node programmers have another option (other than the daemon) if they want to use our stuff, and so that we can replace the QT UI with an Electron one instead (or maybe even keep both side by side)

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.
Anyway all of this is built using autotools and some helper scripts to handle various things (like the above mentioned node.def situation on windows)

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

[mjmacleod]

Hi @mjmacleod,
Is the following issue correlated with your work?
cmake-js/cmake-js#200

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.

[gabrielschulhof]

A rough approximation of available N-APIs can be obtained by running

cat src/js_native_api.h | grep NAPI_EXTERN | awk '{print $3;}' | sed -r 's/[(].*$//'

The print $3 above needs to be expanded for the case where we have

NAPI_EXTERN napi_status
napi_do_something_useful(...);

[github-actions]

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.

[mhdawson]

This is currently being discussed in: #855. @mjmacleod if you want to comment on the proposal there that would be great.