On Wed, Dec 9, 2015 at 8:58 PM, Carsten Haitzler <[email protected]> wrote: > On Wed, 9 Dec 2015 17:36:43 -0200 Felipe Magno de Almeida > <[email protected]> said: > >> On Wed, Dec 9, 2015 at 3:36 AM, Carsten Haitzler <[email protected]> >> wrote: >> > On Tue, 8 Dec 2015 14:51:01 -0800 Cedric BAIL <[email protected]> said: >> > >> >> On Mon, Dec 7, 2015 at 10:17 PM, Carsten Haitzler <[email protected]> >> >> wrote: >> >> > On Mon, 7 Dec 2015 20:54:02 -0200 Felipe Magno de Almeida >> >> > <[email protected]> said: >> >> >> We have a policy of not auto-detection for configure and as little >> >> >> optional options as possible. >> >> >> >> >> >> However, the JavaScript binding is a complicated beast because it can >> >> >> be compiled against node.js, or against libv8, or against libv8 and >> >> >> libuv. And this option must be made at autotools configure time. >> >> >> >> >> >> Cedric has proposed the generation would always happen to a specific >> >> >> sub-directory where it could be configured separately and compiled. >> >> >> However, I think this complicates things and I don't really see much >> >> >> benefit. >> >> >> >> >> >> Currently, I have added a --with-js option which can be used as: >> >> >> --with-js=nodejs/--with-js=libv8/--with-js=libuv. >> >> > >> >> > can we do this runtime with dlopen/dlsym fun? >> >> >> >> Highly unlikely due to C++ mangling and the amount of inlined code >> >> difference (think template and friends). >> > >> > not v8 - we have to compile against v8 headers and a libv8.. but what about >> > libuv, other node.js symbols that are exported that we might rely on. >> > these? >> > >> > v8 is common here and we rely on c++ api/abi and linking to build - so that >> > stays as-is, but the othe rbits.. can we dl*() them at ruuntime? >> >> I think libuv it seems we could. I'm not sure about node.js. I'll have to >> check. >> >> Do you mean to compile-in node.js and libuv always? That makes sense. > > yes. then we dont have to compile-time choose if its pure v8 or v8+node+uv > >> The only problem is where to find the v8 header. The location priority >> for the headers is different depending if it is compilled for node.js >> or not. If it uses the wrong header, it will break because it is not >> ABI-compatible. > > aaaaah ok. that's an issue. hmmm. and the v8 shipped with node may differ from > a libv8 installed and even if we were to ship our own v8 headers "magically" - > these may not match either. argh. ok. painful. > > one thing here. a non-node version is far less useful. without a runtime, just > linking against v8 is pretty useless, unless we provide that runtime > ourselves... right?
The idea of allowing using libv8 directly is that the user could use EFL binding embedded in an application. And then themselves would actually interpret and run the JavaScript code and register the EFL runtime directly, by initializing it through the register_* functions. This allows great flexibility on how to run JavaScript code with EFL. However, it requires the user to deal with libv8 directly and write C++ code to make use of this. The EFL could itself create a libv8 interpreter and register manually, for example, to allow JavaScript code in edje without node.js but with access to the whole binding. This could be how Bob would begin. > >> Regards, >> -- >> Felipe Magno de Almeida Regards, -- Felipe Magno de Almeida ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
