On Thu, 10 Dec 2015 09:49:00 -0200 Felipe Magno de Almeida <[email protected]> said:
> 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. isn't that kind of hard given v8 changes abi a lot? unless app itself provides v8 - then we have the same node issue? > 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. tho bob was ... lua :) > > > >> Regards, > >> -- > >> Felipe Magno de Almeida > > Regards, > -- > Felipe Magno de Almeida > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
