On Fri, Apr 25, 2014 at 5:42 PM, Mike Hoye <mh...@mozilla.com> wrote: > On 2014-04-25, 3:31 AM, Henri Sivonen wrote: >> On Thu, Apr 24, 2014 at 4:20 PM, Benoit Jacob <jacob.benoi...@gmail.com> >> wrote: >>>> * How should we identify code that we build but that isn't used >>>> anywhere? >>> >>> I'm afraid we need humans for that. >> >> Yeah, but how do we get humans to do that? >> > We ask them! There are thousands of people out there who want to help us do > stuff, if we can give them the right stuff to do.
People out there aren't well positioned to know what needs to be removed even if they could help with the removals. If we want to get rid of cruft, we need core developers to identify cruft. On Fri, Apr 25, 2014 at 7:20 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2014-04-25, 3:31 AM, Henri Sivonen 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. >> >> http://apps.icu-project.org/datacustom/ gives a good idea of what >> there is to turn off. > > Are you looking into these? They all seem like great things to investigate. I haven't looked into Ustdio. Other than that, it seem the stuff on my list above is already turned off. Yay. However, I noticed that we aren't turning off ICU IDNA but we should: https://bugzilla.mozilla.org/show_bug.cgi?id=1002435 And we aren't (except on Mac) building with the assumption that char* always points to UTF-8, which, AFAICT, we should do, since we feed ICU using UTF-16 ourselves and aren't supposed to be asking ICU to call random system APIs on our behalf: https://bugzilla.mozilla.org/show_bug.cgi?id=1002437 >> 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. > > > You need to ask Waldo about that, I think, since he is the person who did > the latest ICU update. The main problem here isn't the configurability of the build system per se. The problem is that parts of the build system itself depend on first building components we shouldn't be shipping! Upstream bug filed: http://bugs.icu-project.org/trac/ticket/10868 >>>> * Do we have any mechanisms in place for preventing stuff like the >>>> ICU encoding converters becoming part of the building the future? >>> >>> No, that is not possible to automate. >> >> I was thinking of policy / review solutions. > > Oh I see. I think this should be part of the normal code review process > already. But perhaps we just need to act on it better. I can't think of > any policy changes which would be of a substantial help OK. On Sat, Apr 26, 2014 at 11:36 PM, Jeff Walden <jwalden+...@mit.edu> wrote: >> * Do we have any mechanisms in place for preventing stuff like the >> ICU encoding converters becoming part of the building the future? When >> people propose to import third-party code, do reviewers typically ask >> if we are importing more than we intend to use? Clearly, considering >> that it is hard to get people to remove unused code from the build >> after the code has landed, we shouldn't have allowed code like the ICU >> encoding converters to become part of the build in the first place? > > I agree in spirit, but this is kind of pedantic. I really don't think > "clearly" is so obviously true, Fair enough. > given that by nature of how we use ICU, we're only feeding it > UChar/jschar/char16_t UTF-16 strings, so it's totally non-obvious > how ICU encoders would ever be triggered. Indeed, they never should be triggered. > (Conceivably they might be invoked in the back end when > reading locale data from the file system, but that's presumably > correctly encoded not as UTF-7 or so. The data is supposed to be baked into DLL data, so there isn't supposed to be that kind of IO. It turns out the problem is that the build-time tools that munge the non-converter data into DLL data themselves depend on the ICU converter subsystem and are built as part of the build! >> I remember that back when Norbert first presented his Intl implementation >> work at the JS work week in 2012, we discussed the impact ICU would have on >> download size. 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 happened. We removed a number of things like collation rules, some of the > ICU components, and more beyond that. Hopefully we didn't remove collation rules, since that's the part we are supposed to be using ICU for! :-) > That's reasonably accurate, combined with the basic steps to prune size and > built code having already been taken. Indeed. The ICU build config is already reasonable to the extent the upstream allows except for minor tuning per above. New question: We have various scriptable nsIFoo stuff (e.g. nsIParserService, nsIScriptableUConv) on the fringes of Gecko for use by mailnews, the Firefox UI or extensions. Since Gaia doesn't use XPCOM, those things are dead code in B2G, right? Would it make sense to invest time in #ifdefing them out for B2G? Or are they already left out by some mechanism not obvious to me? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
