xpconnect depends on intl

VERIFIED FIXED

Status

()

VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: alecf, Assigned: dbradley)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
As a part of the stuff I'm doing in bug 100214, the implicit dependency that
xpconnect has on the "unicharutil" module is about to become explicit. Basically
we need to include nsUnicharUtils.h in order to get the global IsUpperCase that
will replace nsCRT::ToUpper on line 2414 of xpcwrappednative.cpp.

I say "will" because I'm assuming this bug will be looked at before I finish
landing bug 100214... however I have added the inclusion of nsUnicharUtils.h in
preparation for this landing.. that's what exposed this dependency.
(Reporter)

Updated

17 years ago
Blocks: 100107

Comment 1

17 years ago
You need to not break the XPCONNECT_STANDALONE build. This currently means that 
any dependency on intl stuff needs to be condtionally nop'd if 
XPCONNECT_STANDALONE is #define'd. This also means making the REQUIRES changes 
conditional in the makefiles too.

I'm wondering if we shouldn't just hack the uses of nsCRT::IsUpper and 
nsCRT::ToLower in HandlePossibleNameCaseError to just act like the char in 
question has a high byte of zero and then just use the ascii versions of the 
methods. I just don't think this debug mode code is going to suffer many 
(if any, ever! )false positives if we do that.
Let's test the leading char for a high byte of zero, and only fold-and-check if
so.  No false positives, few false negatives.

Comment 3

17 years ago
Created attachment 54588 [details] [diff] [review]
I thought of that too.
(Reporter)

Comment 4

17 years ago
Comment on attachment 54588 [details] [diff] [review]
I thought of that too.

coolness.. I like the idea as well. I'll r=alecf so mike can be the sr=
Attachment #54588 - Flags: review+
Comment on attachment 54588 [details] [diff] [review]
I thought of that too.

Righteous.
Attachment #54588 - Flags: superreview+
(Reporter)

Comment 6

17 years ago
oh, and as a side note, I'm getting very close to actually _removing_
XPCOM_STANDALONE :) - just a few more ugly dependencies to clean up.
(Assignee)

Comment 7

17 years ago
jband, since you were good enough to produce the patch, you want me to handle
the check-in?
Status: NEW → ASSIGNED

Comment 8

17 years ago
dbradley: that would be great. Thanks.
(Reporter)

Comment 9

17 years ago
everything has been checked in, marking this puppy fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 10

17 years ago
Marking Verified -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.