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.

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.

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.

Split Fred's complaint out into bug 434532.

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

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 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.

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

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

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>.

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/.

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.

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.

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.

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.

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.

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?

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