Modules: adding load linked modules feature

[thlorenz]

This PR is mainly to get some guidance if I'm on the right track (i.e. what @tjfontaine had in mind).
It enables to include C++ modules simply by adding them to the node.gyp file and loading them from JS via process.linkedBinding.

It is based on v0.12, but I can rebase on master if that is better.
Please lmk what else needs to be done to get this completed, i.e do we need tests (a little hard to do since it needs to rebuild node to run) and/or an example of how this is used?

• introduced NM_F_LINKED flag to identify linked modules
• setting node_is_initialized after calling V8::Initialize in order to
  make the right decision during initial module registration
• introduced modlist_linked in order to track modules that were
  pre-registered in order to complete it once node is initialized
• completing registration of linked module similarly to the way it's
  done inside DLOpen

Example

Assuming src/simple.cc registers itself via:

void init_simple(v8::Handle<v8::Object> exports) {
  NODE_SET_METHOD(exports, "simple", Simple);
}

NODE_MODULE(simple, init_simple)

node.gyp addition

This addition can be done manually or via nad which injects parameters derived from the existing binding.gyp into node.gyp via a simple command.

{
"conditions": [
        [
          "simple_addon==\"true\"",
          {
            "sources": [
              "addons/simple/src/simple.cc",
            ],
         }
    ]
  ]
}

Loading inside simple.js

var binding = process._linkedBinding('simple');

[trevnorris]

Instead do the following:

exports = cache->Get(module).As<Object>();
if (cache->IsObject())
  return args.GetReturnValue().Set(exports);

[thlorenz]

I got these snippets from somewhere else in node.cc actually. Is the above new for what's currently in master?
I was gonna remove this duplication once I got the go ahead on the general approach.

So most of this comes from Binding(). Should we change the code there as well and/or consolidate into a reusable function to avoid duplication?

[trevnorris]

It's just a different way of accomplishing the same thing. Don't bother changing the code anywhere that isn't directly involved with your code changes.

[trevnorris]

Left a couple style comments.

To make sure I understand correctly, this is a feature that allows injecting code directly into the Node build?

[thlorenz]

Yes, all you'd need to change is node.gyp file and rebuild. Then you could work on whatever you are doing as part of the node build, especially useful for addon development.

Wanted to point out again that this is based on v0.12 branch. Is that correct or do I need to rebase on something else?

[trevnorris]

Well, since master is behind v0.12, and we're just going to merge v0.12 into master once it's released just keep it as-is. Whether this is merged into v0.12 I'll leave open.

/cc @tjfontaine @indutny

[thlorenz]

@trevnorris I updated this PR to match the style you indicated and tested (manually) that the feature still works the same way.

Do we need to add an example or some way to at least manually test this feature somewhere?
I would't mind adding an integration test that involves adapting the node.gyp file and rebuilding. Obviously that would be an isolated test that is run separately, i.e. not part of the tests that run on every build.

[trevnorris]

ping @indutny @tjfontaine What are your thoughts on this patch?

[indutny]

space between ) and {

[indutny]

One nit, otherwise LGTM. Let's land it in v0.12

[thlorenz]

@indutny fixed the nit, waiting for @tjfontaine to reply to #8386 (comment).
The way it is currently will work, but if my approach is very different from what was intended I may have to redo it, we'll see.

[thlorenz]

Just as a note, I hid the linkedBinding function behind a _ for now to make it more feasible to merge this now even if we have to change the API later.

[trevnorris]

Since the API is "hidden" going ahead and merging it. We can work out the details with usage and make it public in the future. Landed in c131c1f.