Release for Solaris/SmartOS

[lloeki]

We 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 it would be much better if those platforms were having binary releases right here.

Getting those built is a pain, so we're working with upstream NodeJS to have those libv8 static libs built and published publicly as part of their CI, as described here which will possibly unfold to also include Windows and FreeBSD.

[nightpool]

As i mentioned in #291, I'm not sure I'm comfortable with bringing the complexity of supporting these operating systems into libv8 if upstream isn't going to support them, but I'm tentatively interested in the plan you lay out with Node's build system. Has there been any movement on this topic recently? Who is your point of contact with Node / is there a tracking issue I can follow here?

[lloeki]

Thanks for the interest @nightpool!

As i mentioned in #291, I'm not sure I'm comfortable with bringing the complexity of supporting these operating systems into libv8 if upstream isn't going to support them

Having to currently maintain it, we had basically the same rationale here, hence:

• the attempt to move (and collaborate) as upstream as possible so that the work (both workload and end result) is shared
• the look towards Node (whose upstream supports SmartOS and musl)

I'm tentatively interested in the plan you lay out with Node's build system.

Since libv8 is an intermediate step of the Node build process, we fetch a given Node source and build only libv8 from there.

Pro: it's astoundingly easier and more reliable to fetch and build libv8 this way than with depot-tools. Con: We can only pick livb8 versions that get packaged with Node.

Has there been any movement on this topic recently?

None that I know of.

Who is your point of contact with Node

Node-side, that would be @joyeecheung and @ryzokuken, which we (Sqreen) contracted with for a short while.

I hear (someone correct me on that) that Node-side they were interested in building and publishing those libv8 libs in some way to stop having to repeatedly build libv8 as part of day-to-day Node development.

@vdeturckheim is our local Node dev and upstream contributor who bridged us, maybe any of them have better ideas as to who to reach out to to get the ball rolling.

is there a tracking issue I can follow here?

We have a public repository here: https://github.com/sqreen/node-v8-monolith

Here is the PR that tracked the work to build libv8 7.3 from Node: https://github.com/sqreen/node-v8-monolith/pull/1

FYI this also involved @nizox, another one of our team members and current maintainer of PyMiniRacer, who faces similar issues (although IIUC he embeds libv8 instead of having it a separate python package).

[lloeki]

Moving discussion to better-scoped #304

[ryzokuken]

Thanks @lloeki for pinging me here directly.

I'm not sure I'm comfortable with bringing the complexity of supporting these operating systems into libv8 if upstream isn't going to support them

Node.js does infact support building on these platforms and would continue to do so for the foreseeable future. Node.js currently does it using their self-maintained python build system gyp-next (https://github.com/nodejs/gyp-next) and any changes to the build process (a switch to GN, CMake or a hybrid are being discussed currently) would be done keeping these platforms in mind.

Reference: https://github.com/nodejs/node/blob/master/BUILDING.md#platform-list

[lloeki]

libv8-node doesn't publish Soalris gems but the ruby platform gem should build on Solaris.

[lloeki]

Closing as libv8-node supports that (from source). We can't build binaries as we don't have access to Solaris/SmartOS infrastructure. Maybe cross-compilation is an option (depends on whether we can have a sysroot) but that's much better tackled at libv8-node anyway.