Ehsan Akhgari wrote: > Brian Smith wrote: > > 2. AFAICT, we did not seriously investigate the possibility of > > splitting things out of libxul more. So far we've tried cutting > > things off the top of the dependency tree. Maybe now we need to try > > cutting things off the bottom of the dependency tree. > > Can you please give some examples? Let's remember the days before > libxul. It's hard to always make sure that you're accessing things > that are properly exported from the target library, deal with > internal and external APIs, etc.
Any of the non-XPCOM code (most of it imported?) like ipc/ a huge chunk of the underlying code for WebRTC. (I know we already are planning to split out that WebRTC code from libxul.) Unfortunately, I am mostly a post-libxul Mozillian, so it would be better to have the XPCOM old-timers weigh in on the difficulty of having multiple libraries in Gecko. I guess the problem with splitting is that almost everything depends on XPCOM which is at the bottom of the libxul dependency tree. So, if we try to split things from the bottom, the first thing we'd have to move is XPCOM. But then we have to deal with internal vs. external XPCOM interfaces. Because I didn't have to deal with that issue before (which was pre-libxul), I cannot estimate how much effort and/or how much performance cost (e.g. relocation overhead) that would have. Also, I am not sure how much the internal vs. external issue was to deal with the need for a stable ABI vs. solving other problems like relocation overhead. Definitely we wouldn't need to have the stable ABI requirement for a split libxul, so perhaps the internal vs. external issue wouldn't be as painful as before? Also, from looking at a few parts of the code, it looks like we're already having to deal with this internal vs. external API problem to a certain extent for WebRTC. I do agree that this would be a non-trivial project. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
