search

phpv8 / v8js

V8 Javascript Engine for PHP — This PHP extension embeds the Google V8 Javascript Engine
http://pecl.php.net/package/v8js
MIT License
1.83k stars 200 forks source link

Include v8 in repository #114

Closed rauchg closed 9 years ago

rauchg commented 9 years ago

Just like node does:

https://github.com/joyent/node/tree/master/deps/v8

I think having to clone and compile your own v8 separately introduces a significant barrier to entry to v8js. Also, in general, making the default example install a global version of v8 is probably suboptimal, since most people will be compiling v8 for this project alone.

rosmo commented 9 years ago

Can we add a preferred V8 as a submodule (since V8 is going git) and a flag not to use the built-in one? (since some distributions bundle their own V8 builds)

satoshi75nakamoto commented 9 years ago

:+1: I like it.

stesie commented 9 years ago

I like the idea as well.

Someone willing to work on that? Otherwise I'll have a go the next days.

I think adding v8 as a submodule is definitely the way to go, then we can still support the --with-v8js options, not breaking existing builds. And if the option is omitted, the internal v8 is used (as long as the submodule was checked out correctly)

Besides we can set up a Jenkins job, that regularly builds against most recent v8 version and updates the submodule reference on success.

cheers ~stesie

rauchg commented 9 years ago

I recommend syncing the subtree directly, not using submodules. Submodules are hard to use and they're not really that beneficial.

stesie commented 9 years ago

I think it might make sense to include a v8 checkout in a release tarball.

I don't see why submodules should be hard to use, after all it's as simple as passing --recurse to git clone. Otherwise we'd just blow up our repository for no benefit, since I don't see why we would want to patch it...

And after all even the v8 source tree doesn't include all what's needed, i.e. gyp, libicu, etc.pp If we'd include v8 we probably would want to include depot tools as well, ...

cheers ~stesie

stesie commented 9 years ago

hmm, I had another look at the topic, had a try, and I think it's not really practical.

The point is, if you compile v8 without library=shared it does compile without -fPIC, i.e. doesn't compile position independent code. This is it cannot simply be linked into V8Js which must be compiled as a shared object file -- otherwise it wouldn't be loadable as a PHP module. It should be possible to statically link V8Js + V8 directly into PHP. But I think that's not what you're after.

The difference to node is that node is compiled & linked as an executable, which doesn't need position independet code.

So I think it's not quite possible to get rid of the global installation of v8 shared library. The only thing we could do is provide a script which automatically compiles & installs v8 (+ libicu) but that's not really much advantage.

cheers ~stesie

rauchg commented 9 years ago

Even if it's compiled a shared object file, I do think there's a benefit to v8js's make building its own, path-prefixed v8?

Essentially, my idea was for the default installation behavior to do this:

If you don't want to overwrite the system copy of v8, replace /usr in the above commands with /tmp/v8-install and then add --with-v8js=/tmp/v8-install to the php-v8js ./configure command below.

on behalf of the user. I think most users won't havea global shared v8 install that they are adamant about reusing, but YMMV.

stesie commented 9 years ago

I think "make install", i.e. installing off the distributions package management, is generally a bad idea ... and thus shipping some kind of shell script that automatically builds v8, installs it off /usr and compile v8js against that likely is... besides it's probably dependant on the OS distribution what it should be like.

If you argue that it's a barrier to V8Js that it's complicated to install it, than it's probably more promising to have packages for popular distributions ... and I already provide a docker image with it installed

cheers ~stesie

rauchg commented 9 years ago

Yeah, Docker might be the solution here. Will give it a shot.

stesie commented 9 years ago

I created Debian & Ubuntu packages, see #96, which handle v8 installation as described above, i.e. install off /usr/lib and rpath to there.

Besides that I don't think it's quite possible to auto-install v8 & co. on pecl install v8js, since v8 installation is heavily system dependent (don't know what the steps would be on windows, for example)

Hence I would like to close this issue, ... Debian & Ubuntu packages + Docker images should simplify affairs for a substantial part of prospective v8js users ... but we can't help them all with appropriate effort

cheers ~stesie

carlos22 commented 9 years ago

The Ruby Racer [1] uses libv8 to provide an easy gem install - but the libv8 gem project is really outdated. Don't know if we can do something similar? I'm not aware of all pecl features.

since v8 installation is heavily system dependent

It is system dependent, but I would ignore windows systems and just provide binaries for windows, because this is what most of the windows users are used to...

[1] https://github.com/cowboyd/therubyracer [2] https://github.com/cowboyd/libv8

stesie commented 9 years ago

I had a quick look at the PECL documentation, but I don't think it's possible to install a system library using it ... or at least not without a lot of hacks.

stesie commented 9 years ago

Closing this now, since there's nothing clever we can do that fits all platforms.

For example building on Windows is so very different that it isn't beneficial at all if we ship a v8 including bundle. And on Linux there's no way to link v8 right into the v8js.so file, hence we would always need to hide extra .so files somewhere from the library loader.