Closed
Bug 315090
Opened 19 years ago
Closed 19 years ago
Convert xpconnect utils/tests to use frozen linkage
Categories
(Core :: XPConnect, defect, P1)
Core
XPConnect
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: benjamin, Assigned: benjamin)
References
Details
(Whiteboard: [has patch])
Attachments
(1 file)
In preparation for stopping exporting nonfrozen functions from libxul, I'm going through the tree and fixing the various tests that currently use the internal linkage to use frozen linkage. This bug is about the various test directories under js/src/xpconnect
Assignee | ||
Comment 1•19 years ago
|
||
Attachment #201862 -
Flags: review?(dbradley)
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [has patch]
Comment 2•19 years ago
|
||
Why are the includes needed in the second hunk? +#include "nsServiceManagerUtils.h" +#include "nsComponentManagerUtils.h"
Assignee | ||
Comment 3•19 years ago
|
||
nsIComponentManager.idl onlny includes the Utils file when MOZILLA_INTERNAL_API is defined.
Assignee | ||
Updated•19 years ago
|
Attachment #201862 -
Flags: review?(dbradley) → review?(shaver)
Comment on attachment 201862 [details] [diff] [review] xpcshell and test with glue, don't build test/component because we can't link with nsVariant r=shaver, though it's a shame we can't build all the tests -- is there a bug that we can use to track making nsVariant or some equivalent thing available via a frozen API?
Attachment #201862 -
Flags: review?(shaver) → review+
Assignee | ||
Comment 5•19 years ago
|
||
Fixed on trunk. I tried to expose nsVariant and then ran into problems with needing NSPR (could be solved by not providing nsVariant in the standalone glue): how much do we want to expose that class directly in the glue and how much do we just want to encourage use of the nsIVariant interface?
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•