From my perspective the goal would be to access classes such as nsIOService directly instead of via getService + abstract classes.

This would kill an add-ons ability to override these classes, yes?

At a glance, it looks like this is certainly an improvement. Might make it difficult to achieve bug 462464, though. (Since all the stuff that was in tier_external is still likely to be parallelizable.)

(In reply to comment #1) > This would kill an add-ons ability to override these classes, yes? Not really, since the initial get would still go through the service manager -- it would kill their ability to overwrite them after init, though.

FWIW, the question of which XPCOM services have fast getters should be dealt with in bug 516085. This bug is just for the build machinery necessary to include headers and stop jumping through so many hoops.

This also removes some of the tools_tier_foo hackery so that now we just do export/libs/tools for each tier in turn.

Comment on attachment 412973 [details] [diff] [review] One big tier_platform, rev. 2 >diff --git a/netwerk/build.mk b/netwerk/build.mk >--- a/netwerk/build.mk >+++ b/netwerk/build.mk >@@ -29,55 +29,38 @@ > # use your version of this file under the terms of the MPL, indicate your > # decision by deleting the provisions above and replace them with the notice > # and other provisions required by the GPL or the LGPL. If you do not delete > # the provisions above, a recipient may use your version of this file under > # the terms of any one of the MPL, the GPL or the LGPL. > # > # ***** END LICENSE BLOCK ***** > >-# NOTE: We need NSPR and xpcom, but their build.mk may or may not be >-# included yet. Include it if needed. >- >-ifndef tier_nspr_dirs >-include $(topsrcdir)/config/nspr/build.mk >-endif >- >-ifndef tier_xpcom_dirs >-include $(topsrcdir)/xpcom/build.mk >-endif >- >-TIERS += zlib \ >- necko \ >- $(NULL) If you're going to so thoroughly neuter this file, what's the point of keeping it? Why not just move its content into toolkit-tiers wholesale? (Same question for xpcom/build.mk.) I doubt we've supported building standalone necko or xpcom in a while anyway, so might as well completely drop the pretense.

Did you want to update this patch and land it?

Yes, eventually, but I've been distracted.

This patch is an un-bitrotted version of Benjamin's, but also applied to the Electrolysis branch.