User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.8.0.1) Gecko/20060313 Debian/1.5.dfsg+1.5.0.1-4 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.8.0.1) Gecko/20060313 Debian/1.5.dfsg+1.5.0.1-4 Firefox/1.5.0.1 Please allow to build a standalone js (spidermonkey) binary while building, for example, firefox. Patch coming. Reproducible: Always

(note this patch is against xulrunner 1.8.0.1 ; should apply correctly on trunk)

You mean jsshell? What do we need to build that for? I'm not absolutely opposed, but I'd like to understand.

We have a jsshell in debian that used to be built using the spidermonkey tarball, which was not updated often, and is now aging in your ftp archive. We now provide this shell from the xulrunner source code.

Comment on attachment 216329 [details] [diff] [review] Patch ohh yes this would be nice. why not build this always, instead of making it conditional on a configure switch? I think we have too many of those already.

Well, tell me what you all agree to have and I'll adapt the patch (binary name, option name or no option at all, whatever...)

Can the xpcshell (in js/src/xpconnect/shell) get in on the libreadline configure goodness?

See also bug 97954 and bug 62307. It would be *great* to have a unified build system for standalone SpiderMonkey and built-into-Mozilla-apps libmozjs. There will be a SpiderMonkey JS1.6 rc1 tarball soon, btw. /be

Could we reasonably call this a dupe of bug 97954? Mike: I would be happy to work with you on this, if you're still interested in it. Ideally, js/ should have its own configure script compatible with the main tree build but capable of being run on its own.

Taking ownership of this until it is marked as a dupe (if ever)

I'm not sure I like the idea for a small part of the tree to use automake and libtool where all the rest only use autoconf... I'd be much more in favor of something like what is currently done with nsprpub

I agree, we want to use an autoconf + rules.mk solution similar to NSPR, not jump into automake.

Okay, I will model my work on the NSPR stuff then. Can we close the other bug, perhaps? WONTFIX?

There is a lot wrong with this patch. I have (I think incorrectly) changed the DEPTH= setting in Makefile.in, and stolen configure.in and some files from config/ from the nsprpub/ build. Where obvious, I have changed the names of nspr things to be "js" things or removed things that didn't make sense. I also used autoscan to update configure.in automagically. I've probably missed parts, and broken things. Applying this patch will probably require you to manually create a config/ directory under js/

I need to add a sane "all" target (or something) to Makefile.in to convince it the generated makefile that there is still some work to do. Also, it would be nice to have a toplevel Makefile that calls the Makefile in js/src (even if that's all it does).

Instead of producing browser-specific jsshel (or js) executables, IMO, spidermonkey should be decoupled from the browsers (like NSS and NSPR are), and made available separately. Currently, the most recently released is js-1.5.tar.gz, which is over a year old. Comparing its contents with mozilla/js subdirectory of Firefox-2.0 reveals numerous changes. Configuring firefox ``--with-system-js'' should be THE PREFERRED way. Following it, the various Mozilla software packages will be able to share one more component (in addition to NSS and NSPR) -- instead of each package building their own. And that would be a good thing...

Mikhail: That's the plan (though it might be easier to do the autoconf thing in the context of Moz2). Also, there should be a js-1.6 either currently staged, or coming soon.

As suggested in comment #6

(In reply to comment #15) > Instead of producing browser-specific jsshel (or js) executables, IMO, > spidermonkey should be decoupled from the browsers (like NSS and NSPR are), and > made available separately. > > Currently, the most recently released is js-1.5.tar.gz, which is over a year > old. Comparing its contents with mozilla/js subdirectory of Firefox-2.0 reveals > numerous changes. > > Configuring firefox ``--with-system-js'' should be THE PREFERRED way. Following > it, the various Mozilla software packages will be able to share one more > component (in addition to NSS and NSPR) -- instead of each package building > their own. And that would be a good thing... I'm in favor of this change.

This additional patch is necessary to correctly build with gcc 4.2 using system wrappers instead of -fvisibility=hidden. Without this patch, the build fails with the following error: js/src/js.c:149: undefined reference to `readline' js/src/js.c:153: undefined reference to `add_history' /usr/bin/ld: js: hidden symbol `readline' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status And a similar error with xpcshell.cpp.

What's the status of this bug? Is this something that is wanted for 1.9?

No, I've been sitting on it because we need to do something very different and moz2 changes the linkage problem anyway.

Comment on attachment 216329 [details] [diff] [review] Patch We're not going to do this, in preference for the solution in bug 97954

(In reply to comment #22) > (From update of attachment 216329 [details] [diff] [review]) > We're not going to do this, in preference for the solution in bug 97954 What's meant by "this"? The solution to bug 97954 still calls for a standalone SpiderMonkey tarball, and that's all I was asking for -- two years ago...

jimb might be a better owner. Or should we WONTFIX this?