Sorry, I only now discovered this thread. Below are replies to many of the issues raised with regards to the work I did adding ICU and the ECMAScript Internationalization API early last year.
A lot of background information is in this document (no longer fully up to date): http://lindenbergsoftware.com/mozilla/implementation.html and in Jeff’s more current one: https://wiki.mozilla.org/User:Waldo/Internationalization_API On Apr 24, 2014, at 5:31 , Henri Sivonen <hsivo...@hsivonen.fi> wrote: > * Are we building and shipping dead code in ICU on B2G? B2G doesn’t have ICU and the internationalization API yet: https://bugzilla.mozilla.org/show_bug.cgi?id=866301 …but of course that’s only a short-term fix. On Apr 24, 2014, at 11:31 , ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote: > There is at least some code in ICU that is > - used by FF, but > - not used by TB. As far as I know, the ECMAScript Internationalization API is so far only enabled for desktop Firefox. On Apr 24, 2014, at 5:49 , Till Schneidereit <t...@tillschneidereit.net> wrote: > One idea was to slim down the ICU build and get rid of some > things not needed for Intl. I might very well be mistaken, but I'm not > aware of this having happened. It did happen. ICU has a number of build flags that can be used to reduce code and data size. I used the applicable subset to shrink the binary size to less than half of the size of a full ICU build. Mozilla doesn’t even have the full set of ICU source files – the import script drops the sources for encoding mappings, break iterators, language names and much else. http://mxr.mozilla.org/mozilla-central/source/build/autoconf/icu.m4#145 http://mxr.mozilla.org/mozilla-central/source/build/autoconf/icu.m4#213 http://mxr.mozilla.org/mozilla-central/source/intl/update-icu.sh#32 On Apr 24, 2014, at 16:03 , Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > ... We build and ship *all* of ICU, and presumably ship a tiny portion of it. We don’t – see above. > This is at least in part due to bug 915735, you can go and read the bug to > see that I did the best I could there, given the constraints that I had (not > understanding how the magic of the interaction of ICU and our build system > worked, not understanding which parts of ICU we actually want to use, the > performance and code quality limitations of MSVC's PGO compiler, the fact > that increasing the amount of time we allow our builds to progress is rocket > science, etc. I don’t have numbers for this change specifically, but during my investigation I found that on Mac statically linking ICU into libmozjs reduced the binary size by almost 600KB, compared to building ICU as a separate DLL. On Apr 25, 2014, at 0:31 , Henri Sivonen <hsivo...@hsivonen.fi> wrote: > Therefore, it looks like we should turn off (if we haven't already): > * The ICU LayoutEngine. > * Ustdio > * ICU encoding converters and their mapping tables. > * ICU break iterators and their data. > * ICU transliterators and their data. All done, except for a few remaining encoding converters: > However, that flag is misdesigned in the sense that it considers > US-ASCII, ISO-8859-1, UTF-7, UTF-32, CESU-8, SCSU and BOCU-1 as > non-legacy, even though, frankly, those are legacy, too. (UTF-16 is > legacy also, but it's legacy we need, since both ICU and Gecko are > UTF-16 legacy code bases!) > http://mxr.mozilla.org/mozilla-central/source/intl/icu/source/common/unicode/uconfig.h#267 UTF-16 may be legacy from the point of view of encoding HTML pages, but otherwise it’s an essential part of most of today’s computing environments – and the alternative in many cases would be UTF-32. But at least four of the above are clearly obsolete. > Also, If the ICU build system is an configurable enough, I think we > should consider identifying what parts of ICU we can delete even > though the build system doesn't let us to and then automate the > deletion as a script so that it can be repeated with future imports of > ICU. That seems worth investigating, but getting the build system to strip out as much as possible might be more effective – see the next item. On Apr 25, 2014, at 8:12 , Trevor Saunders <trev.saund...@gmail.com> wrote: > Well, it really depends how you approach the problem of finding code > thats dead. One way is to decide code really should be dead by reading > it and knowing what it accomplishes doesn't matter. Another is to > prove to your self that code is unreachable and so can be removed > without effecting anything. Both of these require a pretty good bit of > knowledge and skill. On the other hand the below question prompts > another approach. Is there a way to give the linker a list of functions that you want to have as public entry points of a dynamically linked library, and have it strip out everything that can’t be reached from these functions? That’s essentially what happens when you statically link a library into another, and the list of ICU functions that Mozilla code calls wouldn’t be excessively long. The bulk of them can be found in this stubs section: http://mxr.mozilla.org/mozilla-central/source/js/src/builtin/Intl.cpp#62 On Apr 28, 2014, at 5:59 , Henri Sivonen <hsivo...@hsivonen.fi> wrote: > I haven't looked into Ustdio. That’s disabled by the --enable-icuio=no flag in http://mxr.mozilla.org/mozilla-central/source/build/autoconf/icu.m4#213 > However, I noticed that we aren't turning off ICU IDNA but we should: > https://bugzilla.mozilla.org/show_bug.cgi?id=1002435 Thanks for finding and fixing this issue, as well as 1002437! On Apr 25, 2014, at 0:31 , Henri Sivonen <hsivo...@hsivonen.fi> wrote: > Using system ICU seems wrong in terms of correctness. That's the > reason why we don't use system ICU on Mac and desktop Linux, right? Correctness from the user’s point of view – quality of locale and time zone data – is clearly an issue (conformance with the Ecma standard is not, as Jeff pointed out). In addition, a system ICU isn’t always available to us: On Mac, it’s not public API; on some Linux versions, it’s built with version numbers baked into function names, which we can’t link against. On May 1, 2014, at 12:25 , Jeff Walden <jwalden+...@mit.edu> wrote: > On 04/28/2014 05:59 AM, Henri Sivonen wrote: >> Hopefully we didn't remove collation rules, since that's the part we >> are supposed to be using ICU for! :-) > > I'm uncertain exactly what the terminology means necessarily for us, but > intl/icu-patches/genrb-omitCollationRules.diff exists because a flag passed > in the ICU build process to "omit collation rules" was broken in 52, and we > had to fix it ourselves. (Well, technically I wrote a patch-fix, submitted > it upstream, then they rewrote it to be sane and I backported it to our tree. > :-) ) So we do omit collation-related data, that was claimed in the code > and elsewhere to be "collation rules", that's not being used by us. A standard ICU build contains localized collation rules in both source and compiled form. The source form is needed to support an ICU API that lets applications tailor the rules to their specific needs. ECMA-402 doesn’t provide such an API, and I don’t think Mozilla will need it, so we’re using the build flag ??? to get rid of the source form. The Collator implementation uses the compiled form. Norbert _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
