After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 636977 - depend on firefox 4
depend on firefox 4
Status: RESOLVED FIXED
Product: gjs
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gjs-maint
gjs-maint
Depends on: 646369
Blocks:
 
 
Reported: 2010-12-10 17:15 UTC by Colin Walters
Modified: 2015-06-24 22:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove all conditional code for API changes in the 4.0 cycle (18.23 KB, patch)
2011-05-17 02:48 UTC, Nirbheek Chauhan
reviewed Details | Review
Remove all conditional code for API deprecated after the 4.0 cycle (3.81 KB, patch)
2011-05-17 02:52 UTC, Nirbheek Chauhan
none Details | Review

Description Colin Walters 2010-12-10 17:15:45 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?
Comment 1 Colin Walters 2010-12-10 17:17:08 UTC
More information: Firefox 4 is due early 2011 which corresponds with the GNOME 3 release, roughly.

https://wiki.mozilla.org/Firefox/4/Beta
Comment 2 Colin Walters 2010-12-10 17:19:23 UTC
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.
Comment 3 Havoc Pennington 2010-12-10 17:28:10 UTC
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.
Comment 4 Colin Walters 2010-12-10 17:34:17 UTC
(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
Comment 5 Colin Walters 2010-12-10 17:37:13 UTC
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.
Comment 6 Havoc Pennington 2010-12-10 17:38:38 UTC
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
Comment 7 Colin Walters 2010-12-10 17:39:35 UTC
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.)
Comment 8 Havoc Pennington 2010-12-10 17:40:50 UTC
if we did a .pc and .so under a different name, we could even increment the soname when the ABI changes
Comment 9 Colin Walters 2010-12-10 17:41:56 UTC
(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!
Comment 10 Colin Walters 2010-12-10 18:23:39 UTC
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.
Comment 11 Josselin Mouette 2010-12-11 08:15:44 UTC
(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.
Comment 12 Josselin Mouette 2010-12-11 11:25:21 UTC
(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.)
Comment 13 Havoc Pennington 2010-12-13 21:27:29 UTC
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.
Comment 14 Christian Persch 2010-12-13 22:26:39 UTC
(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.)
Comment 15 Colin Walters 2011-05-04 18:50:10 UTC
This bug is more relevant after bug 646369 lands; we could consider hard requiring at least 1.8.5.
Comment 16 Colin Walters 2011-05-16 20:30:40 UTC
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.
Comment 17 Nirbheek Chauhan 2011-05-17 02:48:32 UTC
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.
Comment 18 Nirbheek Chauhan 2011-05-17 02:52:42 UTC
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.
Comment 19 Colin Walters 2011-07-20 17:04:44 UTC
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.
Comment 20 Colin Walters 2011-07-20 17:05:21 UTC
Review of attachment 187946 [details] [review]:

Er, Nirbheek - sorry for misspelling your name!
Comment 21 Nirbheek Chauhan 2014-06-03 14:47:20 UTC
Three years later, I think this bug is done and obsolete now. Time to close it? :)
Comment 22 Cosimo Cecchi 2015-06-24 22:56:26 UTC
I think so; further porting to newer versions of Spidermonkey is now tracked in #742249.