mike, some of the issues you may be trying to address are being attacked by: 1) providing a #define which excludes any unsupported APIs from being dragged in 2) a static glue library, which has begun in xpcom/glue - the idea is that a client links against the static library, and the static library provides the mechanism to get to the supported parts of XPCOM.
There are bugs for each of these, I just can't find them Alec Doug Turner wrote: > I am not sure exactly what the point is of having two libraries. I > mean, I would think that we should strive to get some concrete set of > public interfaces and include together and publish these to component > and plugin developers. What does it matter if the there is obsolete > cruft in the library? > > > Mike Shaver wrote: > >> Let's ship libxpcom10.so with Mozilla 1.0. And people who want to use >> plugins that need the nsServiceManager:: and other APIs can install >> libxpcom.so[*] for compatibility. This way we get to build clean >> APIs, and not break anyone that the distributor doesn't want to >> break. We'd need to make libxpcom.so speak "XPCOM 1.0" to >> libxpcom10.so for some things, so that they could share singleton >> services and whatnot, but it really puts the binary compatibility bar >> as high as we're willing to make it. >> >> I've half-thought of the mechanics of mapping contract IDs and >> interfaces around so that everyone sees the things they want to see on >> both sides of the API divide, but I'm too tired to really get into the >> details now. (And it's too large to fit in the margin.) But I think >> the idea at least bears discussing. >> >> [*] On systems with rich enough DSO support, we could probably call >> the real library libxpcom.so and the compatibility library >> libxpcom_obs.so, with appropriate sonames for each. >> >> Mike >> >
