[Webkit-unassigned] [Bug 32452] Port of v8 to work with Gtk webkit

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=32452





--- Comment #32 from Michael Emmel <mike.emmel at gmail.com>  2009-12-20 14:14:58 PST ---
(In reply to comment #31)
> I poked at this, but there is too much going on to be able to do anything
> useful with it.
> 
> Would it be possible to make:
> 1) a separate patch that refactors the makefiles to split out JSC from the
> other webcore files?  I can review and commit that without any v8 bits since
> it's a cleanup.
> 2) a patch that doesn't involve renaming everything?  that will keep the diff
> minimal so I can actually look at it.  (Even a patch that doesn't compile would
> be good.)
> 
> BTW, we spend some time looking at the GTK build this week and managed to
> reduce the slower build caused by JSC considerably:
>   https://bugs.webkit.org/show_bug.cgi?id=32663
> So if that happened to be the reason for looking into v8, it's no longer
> necessary.

Well first the remote debugging to allow debugging of javascript on an embedded
device was the primary reason for the port. The eclipse plugin was patched to
accept and ip address. Other factors are secondary. Longer term it would be
nice to see at least a defacto standard for remote debugging of javascript but
thats a big project. In general getting both engines to work across a variety
of ports and platforms will encourage both to become better benefiting
everyone.

Next I agree with your proposal. If this patch is to be accepted I think the
following needs to be done.

1.) Finish refactoring the makefiles and submission of the refactor patch and
the one with v8 showing a more modular and easier to modify set of makefiles.

Right now I've broken things out into a few more makefiles one per major
component and am working on assigning a few variables per feature.


2.) A second patch with only the changes needed to build minus renaming and
prob debugging support. In some cases I was able to replace engine specific
code with some of the new generic script support. Here these changes need to be
vetted and I think we can do a bit of work on ScriptController/GenericBinding
to remove a lot of engine specific code.
Associated with this would be a patch with just the changes outside of v8
without renaming. Enough to pick up the headers at least.


4.) Let the powers that be decide about renaming these patches will help
everyone including me take a deeper look at the issue. Renaming was invaluable 
in getting something that worked however perhaps its not needed. Regardless a
set of patches without renaming are a must.

Political Statement :)

In general for V8 it would be nice if it was easy to drop into any project that
wanted to use javascript. I use Javascript engines outside of the browser world
and I've found that the JavascriptCore API approach is very useful. Its
incomplete and in some cases I've had to use the direct api but overall it won
as far as ease of use.

A lot of people program in javascript today this large developer base can be
leveraged providing javscript api's for all kinds of applications. Proposals
for the newer versions of the language go a long way to removing some if its
warts. Thus the language itself has a lot of potential. However the lack of a
reasonably complete standard C/C++ api makes integration difficult. So from the
big picture viewpoint I'd argue driving towards a unified C/C++ api should be
considered. Certainly in some cases engine specific features will need to be
used but they should be and exception not the rule. Browsers that allow
multiple engines would also benefit for this expanded base.

I think its worthwhile to bring this point up now not for debate but because I
think its useful to consider and its my underlying big picture view.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.