Packaging -ljs (and V8 from GOOG an ...)

[Jeff Johnson]

The technology wars involved with Mozilla <-> Google <-> Apple <-> Opera
JS libraries have basically obliterated any reasonable conventions for targeting

[herrold (herrold)]

I have a js-1.60-2orc.src.rpm which may suffice ...

[Jeff Johnson (n3npq)]

(aside)
Hmmm ... I continued my original comment but perhaps forgot to hit "Post Comment". Oh well ...
I'll recall & rewrite down the road a bit.

Nope. RSE packaged js-1.6, since then matters have gotten worse.

There's a -ljs-1.70 around (in FreeBSD/rhel6 for sure), but js-1.70 is still too old.

There's js-1.8.1-rcN tarball which is almost good enuf, but that's before TraceMonkey
and does not have JSON internal.

The features of interest (to me anyways) are
    works with GPSEE (that essentially means js-1.8 or better)
    JSON internal
    TraceMonkey (or better)

RHEL6 has managed the XULRUNNER -lmozjs-1.9.1 which
_IS_ gud enuf, except that XULRUNNER has fiddled up the -ljs API/ABI
into an evolutionary dead-end specific to firefox (afaik)

Meanwhile the specific checkout from GPSEE _HAS_ a future growth path
because GPSEE is tracking Mozilla devel directly with _NO_ modifications.

But note that Mozilla has already broken API/ABI in -ljs in multiple ways.

Note that this is NOT simple packaging, nor is there any clear winner.

But the lack of clean packaging and naming is definitely handicapping
"server side JS" usage.

[Jeff Johnson (n3npq)]

The gist of the missing comment ... continued ...

mongo is happy with the Google V8 JS engine (I have yet to see other usages).

The Apple JS offering I have never seen on linux.

There's lots of interesting applications with "server side JS" _BUT_
they are all grabbing some copy of -ljs and diverging. Proper -ljs
packaging MUST start with
    1) assumption of multiple libraries installed on seperate paths.
    2) additional naming because Mozilla (at least) isn't bothering
    with the usual soname API/ABI conventions.
    3) splitting out the internalized goop (like pcre in mongo, and -lffi in Mozilla)
    so that the packaging starts to be properly engineered.

[Jeff Johnson (n3npq)]

Wes notes that -lstdc++ can be dropped if a new/delete ctors/dtors are added.

[Wes Garland (wesgarland)]

A quick note w.r.t. JSAPI (SpiderMonkey versioning):

JSAPI 1.6 - old as the hills, implements JavaScript 1.6
JSAPI 1.7 - Oct 2007, implements JavaScript 1.7
JSAPI 1.8 - Never released, but a js1.8.0-rc1 release candidate was produced. Implements JavaScript 1.8
JSAPI current - There are loose references to JSAPI features in the API documentation talking about JS 1.8.1 and JS 1.8.2, but these aren't real version numbers. They don't correspond to JavaScript language version, and there was no official release. JS 1.8.1 is where the autoconf-based build system and the tracing JIT appeared.

Moz is moving away (at least for now) from packaging JSAPI at all, suggesting that embedders pull from the mozilla-central repository directly; embedders looking for specific "stable" versions should be looking for check-ins tagged for the latest firefox release.

Numbers like 1.9.1 above actually referer to the Mozilla-umbrella version and not to the version of the JavaScript language included or JSAPI; so "1.9.2" refers to any version of spidermonkey that ships with Firefox 3.6.<whatever>.

Note that just because you have two JSAPIs pulled from the 1.9.2 branch, it does not mean that they are ABI or even API compatible. Mozilla is not at all targetting a stable API for embedders these days; they are focused on a fast, correct JS engine. The JS API and ABI can also change based on build options (--enable-threadsafe being the biggest offender here). And you absolutely must not use headers from one JSAPI when compiling code which will be linked with another. Even if they are from the same branch.

GPSEE tracks JSAPI and tries to present a consistent API to the application developer. I intend to version GPSEE sensibly to track JSAPI changes: input welcome.