V8 JavaScript Engine - get patches upstreamed

[cipri]

Port V8 javascript engine.
 http://code.google.com/p/v8/

v8 is important, it could be an improvement for webpositive, but in any case, I need it for improving DocumentViewer? to allow filling forms in pdf documents and other interactive features. It it also used by mupdf in the latest development version, which will be released around february.

I would that somebody else, at least tries to port it. Because if I waste too much time on it, I will later not use that time for the DocumentViewer?.

[hamish]

This is a port of V8 r13067 from the SVN trunk.
gyp is checked out as part of the build process, and the gyp patch should be applied.

At the moment 7 tests fail: 1 due to a Haiku bug, 1 is an expected fail. The other 5 I don't know.

I also had to change the semaphore code to use kernel kit semaphores instead of POSIX semaphores. This probably indicates a bug in the Haiku's POSIX semaphore implementation.

[cipri]

thanks for the patches. Now it should be easy to write a bep file, to have the build process automated.
Related to the posix semaphores, perhaps one should talk to ingo, he is the man to solve that.
It would be just great to have v8 working properly. One step closed to google chrome :-) (I know, I'm still dreaming, but it's the only application that i would like to have in haiku).
Many thanks for your work so far.

[cipri]

i guess the best idea is to write a separte bep file for gyp? and then write a bep file for v8?

[hamish]

A bep for gyp might be overkill as it's just a python script (it has no build/install). The gyp sources would have to be copied into the V8 source tree afterwards anyway...

The V8 build system checks out gyp into build/gyp/ when you run make dependencies. Maybe just a V8 bep would do?

[cipri]

i guess v8 can be pointed to the gyp folder if it's outside. Just a v8 bep would be fine, but I'm not yet sure how the haikuporter can handle two patches at the same time.
Perhaps scott can find a solution.

[hamish]

I don't think V8 can be pointed to gyp. The relative path is hard coded in a python file. Perhaps the second patch command can just be run in the bep after make dependencies?

[scottmc]

Yes. The build and install sections of a bep file can do whatever you can do from the commandline, so if you have a second or third patch to add you can do it using patch there.
If paths are hardcoded, you might try figuring out a way to use finddir or find_directory() to set them. Perhaps even forcing them in using sed.

[cipri]

based on the patches of hamish, i made the patches gyp-r1501.patch and v8-r13067.patch which belong both in normal patches folder.
The bep file is tested and working but not passing all tests. And it builds the package with the -d option and also installs them correctly.
I choosed the header files to go to common/include/V8
and the "output" of the compilation goes to common/V8 for now, because i didn't know where it really belongs, and anyway it can be anytime changed easily in the bep-file. The results of the compilation are not libraries, but binaries which you can use to link against.

After building v8 , one can run "haikuporter --test v8" to start the test of v8, and from about 1.000 tests just about 15 tests are not passing (as far as i noticed). Some of them are crashing.
Some of the tests which are failing are related to threading, so perhaps we can convince ingo to take a look, since this threading problems appear also in the boost port.

[cipri]

The crash reports generated by the debugger while running v8 tests

[cipri]

I updated the bep file. Now the include files go to common/include/v8 , the static and shared libs to go common/lib and the binaries go to common/bin/v8/
i guess it can be made more pretty, but at least it works.
Since not all tests are passed, I set for now it to build as debug and not release.

Please review it, and add it to the haikuporter, so that people can test it.
I'm already using in documentviewer the new libfitzv8 build with v8 support.

[cipri]

Improved bep file

[scottmc]

Applied in r2189. We should probably split gyp out at some point, but this should work for now.

Also the shebangs should be moved out of the patches so that we can get them upstream soon as well. Perhaps change them using sed in the bep or a Haiku section in the build script?

Let's keep this ticket open until the patch(es) get upstreamed.

[hamish]

Thanks for writing the bep. I've been working on fixing those test failures, and I've got it to the stage where only one test fails now. Code is here:  https://github.com/hamishm/v8

I'll write to the v8-dev list to see if they will accept these changes upstream.

[cipri]

great News! Perhaps it could be an idea to write on the Mailing list about that success. Perhaps this will give some other developers some modivations related to v8 (i.e. using it in webpositive, or even fully integrating it in Haiku, since v8 could be used also for a pdf Viewer, etc...).

[scottmc]

The work from this GCI task may or may not still apply here.
 http://www.google-melange.com/gci/task/view/google/gci2012/7972219

[hamish]

The V8 devs don't want this upstreamed, as they understandably do not wish to maintain platform ports which they can't easily test.

[cipri]

Replying to hamish:

The V8 devs don't want this upstreamed, as they understandably do not wish to maintain platform ports which they can't easily test.

Then perhaps it's better to keep your git repository, and write a bep file that pulls the files from your git repo? And perhaps at a later point, they will accept to maintain the haiku port.

[scottmc]

Replying to hamish:

The V8 devs don't want this upstreamed, as they understandably do not wish to maintain platform ports which they can't easily test.

We got the same sort of responce from Python in regards the our 2.x patches. They may at some point accept our 3.x patches but were against adding supoort for new platforms to their legacy code. So we keep the patches here on Haikuports.

Looking at the current v8 patch it certainly can be cleaned up to make it easier for it to be acceptable up stream. For one don't mess with the python shebang lines in the patch, just fix those using sed in the bep. For the haiku platform file, is it that radically different from one off the existing one? Perhaps they here a POSIX one that works for Haiku?

Or we make it easier for them to be able to test it. How are they testing the other X number of platforms? On VMs? Buildbots? Perhaps they have devs setup up boxes that run the tests continuously? What would it take to put the same type of thing together for Haiku?

[hamish]

The Haiku platform file is not much different from the other UNIX-like ones. There's a lot of code duplication between all of them, but with some subtle differences.

As I understand it, a number of platforms in the upstream repo already go untested by the V8 devs, and they don't want to add another to that list. I can keep my Github fork maintained, and that should be sufficient for the moment.

[cipri]

anyone willing to write a .bep for it? And then a package could be added to haiku, so that one can install it, without having to build it everytime.

[richienyhus]

Can this ticket be closed?

Is there any info here that is not on the new site?

[scottmc]

 https://bitbucket.org/haikuports/haikuports/commits/b12de3d
@hamish can you confirm all your changes on this one have been included in the patches on bitbucket and/or upstreamed? Closing this ticket out.