Enable the implementation of the ECMAScript Internationalization API, which has so far been landed disabled, for the JavaScript shell. See bug 853301 for enabling the API on desktop Firefox.

More clearly, this enables the Internationalization API by default for JavaScript standalone builds. When the JS shell is built as part of a Firefox desktop build, the flags for that Firefox build determine what's enabled in the shell, so bug 853301 applies. Enabling the API for standalone builds should help prevent failures as reported in bug 634839 comment 37.

Comment on attachment 742720 [details] [diff] [review] Enable ECMAScript Internationalization API for JavaScript standalone build Review of attachment 742720 [details] [diff] [review]: ----------------------------------------------------------------- Looks fine enough. Although, I did see this in compilation spew: > checking what kind of ordering can be done with the linker... section-ordering-file > checking for posix_fallocate... yes > ../configure: line 15172: SHELL: command not found > export CPP= CC=ccache gcc48 CXX=ccache g++48 CPPFLAGS= -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DUCONFIG_NO_LEGACY_CONVERSION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_BREAK_ITERATION CFLAGS=-fPIC -g -O0 CXXFLAGS=-fPIC -g LDFLAGS= MAKE= I think this may be from the $(SHELL) in configure.in, and it looks like SHELL might only be defined on Windows. Or something. But as long as we're compiling and producing what we want, it doesn't matter too much, I think. This is going to significantly increase shell clobber compilation times. :-\ Probably there's no good way around that. I'll send mail to js-internals letting people know how this can be disabled right now, to avoid the clobber-build compilation hit. In the short run that'll be good enough. In the long run...I dunno. Maybe people just have to get used to a new world where compiling JS takes longer. (How much longer? It looks like it'll add anywhere from a minute to multiple minutes to the compile time. I was inadvertently testing with ccache, initially, so I don't have exact numbers. Hopefully people will use ccache with a good-sized cache, and that'll ameliorate the problem a bit)

> How much longer? Build times on my Mac (with SSD, but no ccache) for a full standalone JS debug build, Internationalization disabled/enabled: real 5m 58s / 7m 07s user 5m 27s / 6m 18s sys 0m 25s / 0m 37s

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #3) > > ../configure: line 15172: SHELL: command not found > > export CPP= CC=ccache gcc48 CXX=ccache g++48 CPPFLAGS= -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DUCONFIG_NO_LEGACY_CONVERSION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_BREAK_ITERATION CFLAGS=-fPIC -g -O0 CXXFLAGS=-fPIC -g LDFLAGS= MAKE= > > I think this may be from the $(SHELL) in configure.in, and it looks like > SHELL might only be defined on Windows. Or something. But as long as we're > compiling and producing what we want, it doesn't matter too much, I think. $(SHELL) is make syntax, but this line gets executed as part of configure and so needs to be in sh syntax. And things worked despite the error because we inserted the shell only in case runConfigure should not be executable, but when obtained straight from hg it is.

https://hg.mozilla.org/integration/mozilla-inbound/rev/533d3fb8a7e9 https://hg.mozilla.org/integration/mozilla-inbound/rev/200003128fd1

https://hg.mozilla.org/mozilla-central/rev/533d3fb8a7e9 https://hg.mozilla.org/mozilla-central/rev/200003128fd1