Get libv8 from elsewhere (e.g Node)

[lloeki]

Context

We (sqreen) currently maintain sideband libv8-alpine (x86_64-linux-musl) and libv8-solaris (x86_64-solaris-2.11, which is what SmartOS is based on) gems, but we thought it would be much better if those platforms were having binary releases right here. Windows and FreeBSD may be on the table in the future for us, which only makes it worse in the current situation.

From depot tools to build system, getting those built is a pain, so we worked with upstream NodeJS to have those libv8 static libs built from the Node source instead of from upstream v8. The fork is here and the PR is here. Our immediate goal was to build 7.3, so it's not up to date.

NodeJS pros and cons

Pros:

• no depot tools: libv8 source code is vendored right in node's tree
• build system: node's repo has the build system set up to build libv8 right away
• more supported platforms: node targets more platforms than libv8, including musl libc, Solaris/smartOS, FreeBSD, AIX even...

Cons:

• dependent on an intermediary (but one who has high interest in having libv8 build widely and easily)
• bound to use only v8 versions that Node uses

Alternative v8 source: Deno

Deno has started to prebuild their own libv8 bindings too, which includes a libv8 source build in the process.

Related issues

Those involve depot tools trouble, lagging updates, and unsupported platforms that cause a failing source build

#289 #270 #291 #279 #271 #270 #259 #253 #260 #217 #261 #285

[lloeki]

I went ahead and created this proof of concept repo, inspired from this libv8 gem. I still have to add readme, license and other boilerplate stuff, streamline things, remove a couple of hacks, but here it is:

https://github.com/sqreen/ruby-libv8-node

It works (x64: macOS + linux-glibc + linux musl) ... with the caveat that there is a significant, mysterious performance issue on some platforms (like, mini_racer tests are 5-10x slower, which seems ludicrous: if Node were -that- slow on those it'd be well known).

Look in Action runs for artifacts, including the unpackaged .a and .h for anyone to peruse as well as the gems themselves.

I'm planning to add ARM and Windows at some point.

@cowboyd @ignisf @SamSaffron I hope you may like this.

[SamSaffron]

Sounds great, I hope this performance issue though is something that can be resolved.

[ignisf]

I also approve in theory

[lloeki]

Tracking the performance issue here: rubyjs/libv8-node#3

[lloeki]

Hey, just an update that the performance thing has been dealt with.

I opened a number of supplemental issues at https://github.com/sqreen/ruby-libv8-node/issues for remaining tasks and road bumps we found along the way.

[lloeki]

So, libv8-node has been released and adopted by mini_racer since 0.4.0. It works fairly well, and the number of cpu and OS platforms is growing.

[lloeki]

Closing as done.