433083 - Build SpiderMonkey stand-alone shell by default

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement)

Description

[Jim Blandy :jimb]

Building SpiderMonkey should also build the stand-alone JavaScript shell, js.

At the moment, the only way to get the shell is to build with Makefile.ref.  Bug 97954 gives SpiderMonkey a stand-alone build system that is the same as the main Mozilla build system, and deletes Makefile.ref.  So with 97954 applied, there's no way to build the shell.

If there's some harm in building the shell by default, then there could be an option to js/src/configure to enable it.  But I don't see any harm, so I think it should simply always be built.

Comment 1

[Fred]

Building JavaScript Shell on WinXP seems to simply not work.  I followed the directions for using Visual Studio 2003 (that is, I installed Microsoft Platform SDK for Windows Server 2003 R2, which took hours).  And I got link errors, starting out like this:
Targeting Windows XP 32 RETAIL


Microsoft (R) Program Maintenance Utility   Version 7.00.8882
Copyright (C) Microsoft Corp 1988-2000. All rights reserved.

        link.exe @C:\DOCUME~1\WARREN~1\LOCALS~1\Temp\nm5.tmp
   Creating library .\Release/js32.lib and object .\Release/js32.exp
jsapi.obj : error LNK2001: unresolved external symbol _js_GeneratorClass
jsapi.obj : error LNK2001: unresolved external symbol _js_IteratorClass
jsapi.obj : error LNK2001: unresolved external symbol _js_StopIterationClass
jsapi.obj : error LNK2001: unresolved external symbol _js_InitIteratorClasses
jsobj.obj : error LNK2001: unresolved external symbol _js_InitIteratorClasses

I've had mercy and not given you all the error messages.  At the very least, you shouldn't give build instructions that don't work.

Comment 2

[Jim Blandy :jimb]

Which build instructions did you follow?  The only way to build the JavaScript shell that I know of is to use js/src/Makefile.ref, but this bug is about the system that will replace Makefile.ref entirely, so descriptions of problems with Makefile.ref aren't helpful here.

Comment 3

[Jason Orendorff [:jorendorff]]

Split Fred's complaint out into bug 434532.

Comment 4

[prlw1]

I thought I had managed that in bug 361268 (just looked at the Makefile.am...)

Comment 5

[Jim Blandy :jimb]

Attachment: Bug 433083: Build SpiderMonkey stand-alone shell by default.

I'm not totally sure about which variables are the right ones to use, but the try server likes this patch on all three platforms.

Comment 6

[(not currently active) Ted Mielczarek]

Comment on attachment 344947 [details] [diff] [review]
Bug 433083: Build SpiderMonkey stand-alone shell by default.

Can you file a followup on making this less sucky? Either by fixing things so js can link against libjs, or fixing the build system to let us produce a static library alongside the shared library. This is fine for now, though.

Comment 7

[Jim Blandy :jimb]

Sure.  This doesn't include line-editing capability.

Comment 8

[Jason Orendorff [:jorendorff]]

pushed http://hg.mozilla.org/mozilla-central/rev/03cb7c55868f

Comment 9

[Daniel Boelzle [:dbo]]

This change seems to have busted the Sunbird tinderboxen (http://tinderbox.mozilla.org/Sunbird/), because we host additional calendar scripts in dist/bin/js/, see <http://mxr.mozilla.org/comm-central/source/calendar/base/src/Makefile.in#117>.

Comment 10

[Daniel Boelzle [:dbo]]

Would it be possible to make building the js standalone optional, so we can omit it for sunbird builds?
Otherwise we'd run into quite some effort maintaining the packaging/update process, because a lot of calendar files are hosted in dist/bin/js/.

Comment 11

[(not currently active) Ted Mielczarek]

You can file a bug on making the js shell optional, with a configure argument to disable it. You might also just move those files to somewhere else. dist/bin/js seems like a very vague location.

Comment 12

[Daniel Boelzle [:dbo]]

Why not call the js shell |jsshell| like it is for |xpcshell| or make it configurable like suggested in comment #0? Sunbird has used that directory long before.

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Because the JS shell has been called 'js' longer than Sunbird's existed :-P. Filing a new bug on making it optional (preferably with a patch!) is still the best way to proceed, though.

Comment 14

[Benjamin Smedberg]

The JS shell has been called "js" since before mozilla was open-source. We aren't going to change it now. The only difference is that we're building it as part of the mozilla build process, so that we can run JS tests as part of our regular build system.

Comment 15

[Daniel Boelzle [:dbo]]

Since we might want to use the js shell for testing, too, it's better to fix the clashing directory instead of going with a configure option; filed bug 462393.

Comment 16

[Phil Ringnalda (:philor)]

Was the actual outcome for what we ship, that Mac Fx, Tb, and SM and Linux Tb (the things that are currently building, and that don't have a packages(-static) file) are now shipping the js shell, and all the other product/platform combinations aren't, what was intended?

Comment 17

[Phil Ringnalda (:philor)]

Oh, I missed bug 462185 (which missed Tb/Linux, to even the missing out).