(2014/04/24 21:49), Till Schneidereit wrote:
(CC'ing people who have worked on the ICU integration)
On Thu, Apr 24, 2014 at 2:31 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote:
However, especially in the context of slimming down our own set of
encoding converters, it's rather demotivating to see that at least on
desktop, we are building ICU encoding converters that we don't use.
See https://bugzilla.mozilla.org/show_bug.cgi?id=944348 . This isn't
even a matter of building code that some might argue we maybe should
use (https://bugzilla.mozilla.org/show_bug.cgi?id=724540). We are even
building ICU encoding converters that we should never use even if we
gave up on our own converters. We're building stuff like BOCU-1 that's
explicitly banned by the HTML spec! (In general, it's uncool that
abandoned researchy stuff like BOCU-1 is included by default in a
widely-used production library like ICU.)
Questions:
* Are we building and shipping dead code in ICU on B2G?
I don't know the state of ICU on B2G, but if we have it enabled there, then
almost certainly, yes.
* The bug about building useless code in ICU has been open since
November. Whose responsibility is it to make sure we stop building
stuff that we don't use in ICU?
I guess that this isn't entirely clear.
* 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 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. We looked at what other vendors were doing
and saw that Google essentially just bundle all of ICU and swallow the
increase in download size. Also, properly integrating ICU into our build
system was a major undertaking in itself, so getting to a point where we
could ship it at all might have taken precedence.
--
till
This is just a random observation, not answering the original questions.
There is at least some code in ICU that is
- used by FF, but
- not used by TB.
I noticed this when I began compiling FF ( under ./mozilla subdirectory
of C-C, which is basically a copy of M-C [could be outdated by a few
patches behind.].
There are a few files which did not compile if I enabled -DDEBUG=1 on my
compilation command line due to broken code within "#ifdef DEBUG",
"#endif". But this compilation failure was only seen during FF build.
TB build using the same tree did not complain about this.
So obviously TB does not use such files.
Just an observation I noticed recently.
Bug 963090 - Compilation error while compiling DEBUG BUILD of Firefox
(C-C) rbnf.cpp, ucbuf.c
https://bugzilla.mozilla.org/show_bug.cgi?id=963090
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
