Building node as a shared library instead of an executable

[kobalicek]

I think that there should be something like libnode.so or node.dll and node executable which simply calls an entry point in the shared object. Then, C++ addons can simply link to a library instead of linking to an executable.

What do you guys think about this?

I remember that there was an option in gyp for that, but all distributions use the executable-only model and I remember the option didn't work out for me even in the past.

I think that node can be used for much more things than just writing servers and having a model that other applications can use seems important. I really think that node can be embedded in other applications. It would be interesting to see more native addons wrapping other libraries and also native addons depending on other native addons (is this possible today?).

Thanks

[bnoordhuis]

I'm afraid I don't have time to summarize it but see nodejs/node-v0.x-archive#7336 for background; the short version is that it's not that simple (unfortunately.)

[kobalicek]

Thanks, interesting discussion.

I think that in such case node shouldn't allow to register custom constructions when building node itself, this responsibility can be moved out and people embedding node would just:

1. Create the environment
2. Register modules
3. Use the environment

The problem I see is that if I create two node addons they export the same symbol. This can be fixed by introducing a naming schema, so for example if the addon is called myaddon the initializer would be something like node_myaddon_init exported as "C". In that case it would be just fixing the loader to hook up the right symbol based on the shared object name, and moving the responsibility on the embedder to call that function when creating the environment.

Well, I think that I see it simpler than it actually is, but I also think this can be fixed.

[rvagg]

It's kind of sad that it was dropped from joyent/node, this is an interesting concept and could be a good addition to the roadmap, it could be great for expanding Node's reach. If there are technical problems then perhaps they can be dealt with simply by limiting the scope of what a shared library is actually able to do. I fear that some of the objection to landing this feature is mostly about waiting for Node internals to be perfect.

@kobalicek (and others), could you outline some of the use-cases you imagine for this?

[Qard]

That "perfect" certainly deserves some quotation marks. I don't think the node codebase will ever fully escape the current hackiness.

[rvagg]

@Qard indeed and it should be embraced lest we be crippled by it and have trouble getting simple releases out the door ... >cough<

[Qard]

Agreed. The pursuit of a clean and friendly codebase is a noble cause, but not at the expense of progress. :)

[kobalicek]

Basically, I would like to see node as a runtime rather than application. For me it would be really interesting to create a native C++ addon for UI and experiment with doing some UI stuff with node. I mean, I don't see it worse to ship some app with libnode instead of libQt.

I'm working on a vector graphics library (blend2d.com) and I have a working node addon, would be nice if it can be used for more than some server image processing in the future ;) However, I see that maybe node is not a right choice for these kind of experiments. I myself see the whole addon system a bit hacky.

But, my question remains, is it possible to create a node addon that depends on or extends another addon?

[rvagg]

Yes, it's sort of possible to make node addons work with each other including depending on each other although it's not done in practice. I did some experimenting with this in https://github.com/rvagg/node-downer-rangedel and the main problem is simply the way npm orders installs and builds but that's mainly due to it not being on the development radar for npm at all.

[kobalicek]

Guys how can I help with this? I'm still definitely interested of having node as a shared library by default.

[bnoordhuis]

@kobalicek I think the following practical issues need to be resolved:

1. Fix auto-registration of built-in native modules.
2. Make the build type for the 'iojs' target in node.gyp configurable, it's always 'executable' now.
3. Add --enable-static and --enable-shared switches to the configure script.
4. Fix the build system so it can build static and shared libraries at the same time (nice to have, not mandatory.) Perhaps it's possible to define an iojs_base target that's depended on by iojs_static and iojs_shared targets.

We can evolve the API as the need arises.