src: export Agent's constructor and destructor

[zcbenz]

Since node::Environment includes node::debugger::Agent as a member data, and the constructor and destructor of node::Environment are inlined, we have to export Agent's constructor and destructor, otherwise when Node is built as shared library we will get following error:

electron_lib.lib(electron_lib.node_main.obj) : error LNK2019: unresolved external symbol "public: __cdecl node::debugger::Agent::~Agent(void)" (??1Agent@debugger@node@@QEAA@XZ) referenced in function "private: __cdecl node::Environment::~Environment(void)" (??1Environment@node@@AEAA@XZ)
electron_lib.lib(electron_lib.atom_renderer_client.obj) : error LNK2001: unresolved external symbol "public: __cdecl node::debugger::Agent::~Agent(void)" (??1Agent@debugger@node@@QEAA@XZ)
electron_lib.lib(electron_lib.atom_renderer_client.obj) : error LNK2019: unresolved external symbol "public: __cdecl node::debugger::Agent::Agent(class node::Environment *)" (??0Agent@debugger@node@@QEAA@PEAVEnvironment@2@@Z) referenced in function "private: __cdecl node::Environment::Environment(class v8::Local<class v8::Context>,struct uv_loop_s *)" (??0Environment@node@@AEAA@V?$Local@VContext@v8@@@v8@@PEAUuv_loop_s@@@Z)

[rvagg]

lgtm

@zcbenz is this the only blocker for you using it as a shared library? was it working properly for electron prior to v4?

[zcbenz]

@rvagg Yeah it is the only blocker, before debugger_agent became a member of node::Environment things worked fine.

[rvagg]

@trevnorris, @bnoordhuis, @indutny any of you care to give this a quick look?

[rvagg]

also #3058 while you're at it

[indutny]

LGTM

[trevnorris]

LGTM

[bnoordhuis]

Wouldn't it make more sense to move the Environment constructor and destructor to src/env.cc? This is leaking an implementation detail.

[zcbenz]

@bnoordhuis Both ways are good to me, I can create a new PR if you prefer that way.

[bnoordhuis]

Moving the constructor and destructor would have my preference. It's more churn initially but more maintainable long-term.

[rvagg]

good call @bnoordhuis, closing in favour of #3098