310105 - NS_InitXPCOM2 in libxul should automatically bring in static components

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect)

Description

[Benjamin Smedberg]

For backwards binary compatibility, NS_InitXPCOM2 should automatically bring in
the gecko static components when it is linked as libxul. This matches the
expected behavior of the embedding API from gecko 1.4 which would have loaded
the gecko components non-statically. NS_InitXPCOM3 without
XRE_GetStaticComponents continues to allow a standalone XPCOM scenario (without
gecko components) if that is really what is desired.

Comment 1

[Benjamin Smedberg]

Attachment: Make NS_InitXPCOM2 use the gecko static components when compiled into libxul, rev. 1

Comment 2

[Benjamin Smedberg]

Note: I'm still in the midst of linking and testing this, but it should do what
we want.

Comment 3

[Darin Fisher]

So, in thinking about this some more, I think it is wrong to make
NS_InitXPCOM2(...) not behave like NS_InitXPCOM3(..., NULL, 0).

I think that in both cases we should load the built-in components.  Like I said
over IRC, built-in components may be components that are statically linked into
the DSO containing the implementation of XPCOM, or they may be the dynamic
components found in the GRE components directory.  From the point of view of the
consumer of this API, there should be no difference.

If a caller wants standalone XPCOM, then they can override the default static
components by passing a non-NULL array of nsStaticModuleInfo objects to
NS_InitXPCOM3.  I don't think we need to support a standalone mode of XPCOM w/
NS_InitXPCOM2 because such a consumer of NS_InitXPCOM2 in Mozilla 1.7 would not
have been without the GRE components.

I don't understand why we need to call out "libxul" in nsXPCOM.h.  Isn't it
enough to speak in general terms about built-in component and then define
built-in components as I have done above?

Comment 4

[Benjamin Smedberg]

> the DSO containing the implementation of XPCOM, or they may be the dynamic
> components found in the GRE components directory.  From the point of view of the
> consumer of this API, there should be no difference.

The "problem" (if there is one) is that unless you initialize XPCOM with a
directoryserviceprovider that returns NS_GRE_DIR, you *won't* get the GRE
components. I'm not sure I care (and I'll have an alternative patch up shortly),
but I want us to realize that we can either be compatible with old usage of
"standalone xpcom" or "xpcom with gre" but not really both.

Comment 5

[Benjamin Smedberg]

Attachment: Make NS_InitXPCOM2 use the gecko static components when compiled into libxul, rev. 2

Take your pick, I'm not sure that I don't still prefer the first version
slightly.

Comment 6

[Darin Fisher]

I think embedding API compat is a MUST, and support standalone xpcom where
someone wasn't specifying NS_GRE_DIR is less important.

Comment 7

[Darin Fisher]

Comment on attachment 197544 [details] [diff] [review]
Make NS_InitXPCOM2 use the gecko static components when compiled into libxul, rev. 2

r=darin

Comment 8

[Benjamin Smedberg]

Comment on attachment 197544 [details] [diff] [review]
Make NS_InitXPCOM2 use the gecko static components when compiled into libxul, rev. 2

Very low risk, for anything except xulrunner ;-)

Comment 9

[Benjamin Smedberg]

Fixed on trunk (attachment 197544 [details] [diff] [review]).

Comment 10

[Benjamin Smedberg]

Fixed on 1.8 branch.