On Mon, Nov 11, 2013 at 05:23:48PM +0200, Henri Sivonen wrote: > We are building and shipping character encoding converters that are > dead code in Firefox but that are used in Thunderbird. Considering the > Firefox binary size, it seems like a bad idea to ship to dead code in > Firefox. > > Currently, this includes the encoders and decoders for UTF-7 and the > IMAP modified UTF-7. However, as > https://bugzilla.mozilla.org/show_bug.cgi?id=863728 and > https://bugzilla.mozilla.org/show_bug.cgi?id=805374 get fixed, many > more encodings will fall into this category. > > In principle, the right way to deal with this would be moving code to > comm-central. However, this would involve annoyances like setting up a > new XPCOM component there and making sure the category manager merges > m-c-defined and c-c-defined category entries correctly. Considering > the de-emphasis on Thunderbird as far as Mozilla-paid development time > goes, it seems unlikely that Thunderbird developers would do the work > soon. On the other hand, looking at this as a Gecko developer, getting > rid of this code in Firefox builds seems like a legitimate way to use > time, but importing the code into comm-central seems less so. > > By far the easiest solution would be leaving the code in m-c but > #ifdefing it out of Firefox builds. Is there a compelling reason not > to do so? If there is no compelling reason against #ifdefing it out in > m-c, what's the right variable to #ifdef on (needs to work in > moz.build and the preprecessor)?
Thunderbird is already linking stuff in libxul from c-c. Why wouldn't it be possible to move those bits to c-c and do the same? Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
