Your input needed on packaging spidermonkey
nickg
Howdy,
I'm sure we are all sick of doing "hg clone" on tracemonkey, and
figuring out what-the-hell is autoconf2.13. I've been working on the
side on a project to package up spidermonkey (and all it's variants).
I've made a modest start @
http://code.google.com/p/packaging-spidermonkey/
You can download pre-autoconf213-ed tarballs.
However after talking with AshB today, it's time to take it to the
next level. Here's a straw man proposal on how version numbering
should be done and code layout.
http://code.google.com/p/packaging-spidermonkey/wiki/Versioning
Your input is very welcome (and needed). I want to nail this quickly
and move on. Suggestions on where to cross post this are welcome.
thanks,
--nickg
Jeff Johnson
If you want, grab a copy of spider-monkey from @rpm5.org in rpm/js.
There is AutoFu (i.e. Automake+libtool+autconf) configgery
sufficient to build spider-monkey 1.8.0 in @rpm5.org rpm/js/* cvs..
Might have rotted a bit in the last month since @rpm5.org is now targeted
GPSEE -> JS rather than building SpiderMonkey directly,
but I can/will repair any damage for you.
hth
73 de Jeff
Jeff Johnson
On Mar 31, 2010, at 7:57 PM, Jeff Johnson wrote:
>
> If you want, grab a copy of spider-monkey from @rpm5.org in rpm/js.
>
> There is AutoFu (i.e. Automake+libtool+autconf) configgery
> sufficient to build spider-monkey 1.8.0 in @rpm5.org rpm/js/* cvs..
>
Sorry, the path should have been js/src (which gets checked out
as rpm/js/src).
Bog standard AutoFu (note no autoconf213 is/was needed).
Caveat:
There's a fairly aggressive backport of JSON from TM into SM in the internal
tree, but its otherwise just a SpiderMonkey tree. No change intended or desired.
The AutoFu should "work" with modern automake+autoconf+libtool no matter what.
There should be cvs labels inside that I can rip out the aggressive backport.
(aside)
The patch WORKEDFORME but I'm not in a position to say YEAH/NAY on the insanity
of the TM->SM JSON backport patch. I needed to imprint the SpiderMonkey code on my retinas, and
the JSON backport sufficed to drag my eyes across a sufficient quantity
of SpiderMonkey code to get oriented).
73 de Jeff
Jeff Johnson
On Mar 31, 2010, at 7:50 PM, nickg wrote:
>
> However after talking with AshB today, it's time to take it to the
> next level. Here's a straw man proposal on how version numbering
> should be done and code layout.
>
> http://code.google.com/p/packaging-spidermonkey/wiki/Versioning
>
Re the versioning proposal:
The real problem isn't the versioning so much as the peculier naming
libjs.a
but
libmozjs.so
(and there's a 3rd name for a dlopen module iirc).
That naming instantly leads to b0rkage writing tests against JS libraries
because the static linking path is different than the shared path.
Not that many do static linking any more, but still ...
There are conventions for library versioning as well that your
propsal doesn't begin to follow. See gnutls (or @rpm5.org swiped from gnutls iirc) versioning
for perhaps a lightly more typical versioning scheme.
You also aren't specifying DT_SONAME and/or DT_NEEDED inside the library,
which is usually more important than pasting some version in the library name.
hth
73 de Jeff