GNOME Bugzilla – Bug 636977
depend on firefox 4
Last modified: 2015-06-24 22:56:26 UTC
Hi, I want to open discussion here about possibly hard-requiring Firefox 4 SpiderMonkey. While we've successfully done all sorts of crazy gymnastics to build on 1.9.2+, I think it's basically unworkable going forward to have gjs tightly coupled to *firefox*. So, we require OS vendors to have a separate "mozilla-js" or "spidermonkey" package. Similarly, for jhbuild, we just pull+build mozilla-central/js/src, not all of mozilla-central. SpiderMonkey already supports this. Thoughts?
More information: Firefox 4 is due early 2011 which corresponds with the GNOME 3 release, roughly. https://wiki.mozilla.org/Firefox/4/Beta
Advantages: * We can toss our crappy ByteArray class in favor of the (really fast) Uint8Array: https://developer.mozilla.org/en/JavaScript_typed_arrays/Uint8Array * Less insane preprocessor macros * We don't have to care about JS_Add*Root anymore * Support is way easier for me Disadvantages: * Can no longer mash together gjs in the same process as an older xulrunner.
What about just sucking spidermonkey into gjs? I did this in https://github.com/havocp/hwf/tree/master/deps/spidermonkey upstream just doesn't really support a system copy, so it's going to be perpetual pain ... litl does not currently need to put gjs into the xulrunner process - in fact we have our own spidermonkey tarball that we build in jhbuild. That's another option would be to make a standalone spidermonkey tarball perhaps.
(In reply to comment #3) > > litl does not currently need to put gjs into the xulrunner process - in fact we > have our own spidermonkey tarball that we build in jhbuild. That's another > option would be to make a standalone spidermonkey tarball perhaps. Yes; if we went this route, I would: * Ask Mozilla to create spidermonkey-X.tar.bz2 tarballs on ftp.mozilla.org * Failing that, do it myself in http://www.gnome.org/~walters
The main tricky part about this is ensuring libmozjs.so and mozilla-js.pc don't conflict with xulrunner. My intuition here is to in gnome-spidermonkey.tar.bz2, rename the .pc file and .so (to gnome-spidermonkey.pc and libgnomespidermonkey.so) respectively, and change gjs to depend on it.
yeah. If you need the tarball we already have it I guess, though it's on an older spidermonkey version so maybe it isn't going to save you a lot of work. But we can send it over. Agree we'd want to rename the .pc and .so
Which argues for the http://www.gnome.org/~walters approach, and possibly doing an import onto git.gnome.org, though I'd rather not go that far =/ Maybe instead have a git module and tarball "gnome-spidermonkey-build" that in git, just contains scripts and tools to wrap around a spidermonkey tarball and rename the resulting library, .pc file etc.)
if we did a .pc and .so under a different name, we could even increment the soname when the ABI changes
(In reply to comment #8) > if we did a .pc and .so under a different name, we could even increment the > soname when the ABI changes Woah man, that's crazy talk!
Additional data: $ ls -al /usr/lib64/xulrunner-1.9.2/libmozjs.so -rwxr-xr-x. 1 root root 1206056 Oct 27 12:13 /usr/lib64/xulrunner-1.9.2/libmozjs.so Fedora 14, x86_64. So we'd be paying the cost of an additional 1.2MB. Seems relatively small, especially since most GNOME-derived OSes ship with all localization which totally dominates disk usage.
(In reply to comment #8) > if we did a .pc and .so under a different name, we could even increment the > soname when the ABI changes FWIW that’s what we already do in Debian, but it’s done in the iceweasel/xulrunner source package itself. Currently, introducing a new Firefox version means updating all libmozjs reverse dependencies together. As for the general proposal, please don’t do that. Code duplication is a maintenance nightmare, and we already went through a lot of pain to reduce the use of system libraries in iceweasel.
(In reply to comment #11) > As for the general proposal, please don’t do that. Code duplication is a > maintenance nightmare, and we already went through a lot of pain to reduce the > use of system libraries in iceweasel. (Of course I meant reducing embedded libraries, in favor of system libraries.)
this is the reverse problem from the usual "system library" problem. Usually you have something maintained as a system library, with proper versioning and ABI and what have you, and then there's an extra copy of it in Firefox. Here, there's something that's a chunk of Firefox internals (basically), which is maintained with an eye to allowing people to cut-and-paste it, but is NOT maintained as a system library - it has no soname, API/ABI stability, etc. The ideal solution is to get it maintained as a system library upstream. But failing that it just does not _work_ as it is, to try to use it as a system library. It needs changes for that. So having a "make it a system library" project makes total sense. Fixing it upstream would be even better, of course, but the clock is kind of ticking on the gnome 3 front.
(See https://bugzilla.mozilla.org/show_bug.cgi?id=506890 for the mozilla developers' response when suggested to make spidermonkey usable as a system library.) (In reply to comment #7) > Which argues for the http://www.gnome.org/~walters approach, and possibly doing > an import onto git.gnome.org, though I'd rather not go that far =/ IMHO an automated hg-to-git import on git.g.o (maybe doing a filtered branch that only includes the js/ dir) _is_ the best way to do this, not some manually rolled tarballs. It's really easy to do --- I have that working here with a mozilla-central clone, using 'hg convert' to strip everything except js/ and then using hg-fast-export.sh to convert to git. > Maybe instead have a git module and tarball "gnome-spidermonkey-build" that in > git, just contains scripts and tools to wrap around a spidermonkey tarball and > rename the resulting library, .pc file etc.)
This bug is more relevant after bug 646369 lands; we could consider hard requiring at least 1.8.5.
So, bug 646369 landed, and I am planning to drop support for xulrunner < 2 in gjs. Anyone wanting to compile against Firefox 3.6/xulrunner 1.9.2.X can use the standalone mozjs-1.8.5 release.
Created attachment 187946 [details] [review] Remove all conditional code for API changes in the 4.0 cycle This is a preliminary patch that requires the changes in bug 644971. It just removes conditional code.
Created attachment 187947 [details] [review] Remove all conditional code for API deprecated after the 4.0 cycle This is a preliminary patch that requires the changes in bug 644971. It just removes conditional code.
Review of attachment 187946 [details] [review]: Hi Nerbheek, sorry for taking so long to get to this. In general, the patch looks clean, and I really appreciate the research that went into the list of functions/bugs. So one complexity going on is that you're working on dropping support for < Firefox 4 and thus removing compile-time checks, whereas Marc-Antoine Perennou in e.g. bug 652041 is working on adding more of them for ongoing Firefox 5+. I've merged this patch with his changes (which are in current HEAD). ::: modules/console.c @@ -197,3 @@ g_free(temp_buf); lineno++; -#ifdef HAVE_JS_DECODEUTF8 It turns out that mozjs185 doesn't have the flag. However, using JS_DECODEUTF8 as the test here is wrong, so I've modified your patch to check explicitly check for the extra flag I added to JS_BufferIsCompilableUnit.
Review of attachment 187946 [details] [review]: Er, Nirbheek - sorry for misspelling your name!
Three years later, I think this bug is done and obsolete now. Time to close it? :)
I think so; further porting to newer versions of Spidermonkey is now tracked in #742249.