On Thu, Apr 17, 2014 at 5:00 PM, Neil <n...@parkwaycc.co.uk> wrote: > Henri Sivonen wrote: > >> I am not done preparing the removal patches yet, but with my current patch >> queue I can already get 149 KB off of Android ARMv7 optimized apk size and >> 138 KB off of Android ARMv7 optimized libxul size. >> > What would be your opinion on the interim use of ifdef (or moz.build > equivalent) to prevent some or all of those files from being built on > browser builds?
I actually asked about this twice. (Message-IDs: <CANXqsRJ=ytet+mhp85z6yqgrg-dush5bpwsejjtfseeqdx+...@mail.gmail.com> and <CANXqsR+hjhLon8CCstjqybV3BA+L4jCuRYCb_vp61Sm=ipy...@mail.gmail.com>; Google Groups seems broken, so I can't link there.) The first time around, I got no reply, so I started a new thread with the #ifdef subject. Nobody told me to go do it or what symbol to #ifdef on. Instead, bsmedberg said we shouldn't do #ifdefs if Linux distros still build Thunderbird on top of XULRunner. Gabriele Svelto took a look at the distros, and there was actually no evidence of the distros building Thunderbird that way. Mike Hommey said: "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?" So I think proponents of #ifdefing had their opportunity to be heard. Now that I've actually prepared some patches and discovered how easy it is to move C++ code from m-c to c-c (at least when c-c is built the normal way), I'm strongly opposed to #ifdefing. Let's be realistic about "interim". I've been unsuccessfully looking for a volunteer to do the easy UTF-7 move since November. Now I've lowered the bar to looking for a volunteer who is familiar with c-c jar manifests to fix a couple of those--still unsuccessfully. If I can't find a c-c developer who could be bothered to fix a couple of jar manifests, realistically, no c-c developer will be bothered to get rid of the #ifdefs later if I instead put some #ifdefs in m-c jar manifests. On Thu, Apr 17, 2014 at 6:52 PM, Kent James <k...@caspia.com> wrote: > Henri, is this work affected by the deadline for the upcoming Gecko 31 to > aurora lift, which effectively determines what is in Thunderbird code for > the next year? > > If not, and if there is any way you could delay your landing until mid-May, > then there would be less pressure on Thunderbird developers. At the moment, > we are trying to land last-minute changes needed for Thunderbird 31 prior to > Gecko 31 hitting comm-aurora. There is no strong need for the m-c removals to be tied to the ESR schedule. However, I think it would be preferable to make the changes before the ESR deadline so that future c-c patches backport easily to the ESR (if there are security holes in the code being moved; and there may well be, since decoders for multibyte encodings are prone to buffer overflows / pointer arithmetic errors) and future m-c patches would backport easily to the m-c ESR, too. Also, at this point, I see pretty much any concern of the form "wait for x" as Stop Energy. On Thu, Apr 17, 2014 at 7:38 PM, Chris Peterson <cpeter...@mozilla.com> wrote: > Note that the current mozilla-central (Gecko 31) will become the next ESR. > If you remove the UTF-7 code now, then TB developers will need to fix their > UTF-7 issues for the next GA release of TB (because it is based on ESRs). It's a code move. Either the moved classes instantiate or they don't. If they don't, IMAP won't work, so it'll be fairly obvious if they fail to instantiate. As far as the UTF-7 move goes, I'm not worried about creating new subtle bugs. The nsCharsetMenu and nsCharsetConverterManager moves will similarly either work or fail very, very obviously. Only the later encoding moves are subtle in the sense that they could be broken and no one might notice. - - Considering that off-list, the sentiment I've heard implies that moving the C++ code is seen as somehow difficult, I think I should clarify what the issues are. Moving the C++ code is not difficult. That is, assuming that Thunderbird is built the way Mozilla builds it with its own libxul. If there's some Linux distro out there that wants to split Thunderbird into two or more packages somehow, that should be entirely their problem to deal with and not something that we should block m-c cleanup on. Fixing jar manifests should be no big deal, either. However, since I happen to be a Gecko developer and not a Firefox UI developer, I'm not familiar with the finer points and conventions of jar manifests on the Firefox side, either, and it seems that with the Thunderbird/SeaMonkey duality, c-c jar manifests are a bit more complicated. Obviously, with enough trial and error I could learn. But spending the time to put together something that would run only to be told by a reviewer to do it differently seems terribly inefficient and a bad use of time when someone who already knows their way around c-c jar manifests could probably finish my patches as a matter of minutes. And let's not forget that I'm not supposed to be working on the c-c side at all--I'm trying to be nice not burning it outright, which, AFAICT, I'd be allowed to do per m-c tree rules. The unit test issue is similar to the jar manifest issue, but probably even easier than jar manifests. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
