Closed Bug 66759 Opened 24 years ago Closed 22 years ago

Removing XPCOM_STANDALONE

Categories

(Core :: XPCOM, defect, P2)

Product:
Core
Component:
XPCOM
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: jonsmirl, Assigned: alecf)

References

Details

(Keywords: meta, topembed-)

Attachments

(2 files)

unbust XPCOM_STANDALONE (again!) looking for r/sr
1.30 KB, patch
Details | Diff | Splinter Review
remove XPCOM_STANDALONE
15.16 KB, patch
dougt
: review+
brendan
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
Another issue: why is there a browser build of  XPCOM and a standalone build of 
XPCOM? Couldn't there be just a single  XPCOM?  NSPR has a single version. 
There are only six XPCOM C  files using XPCOM_STANDALONE. The differences look 
to be fairly  small.

>brendan@eich.org...
In fact, cls@seawood.org has unified the two on the autoconf-based platforms, 
IIRC.  If there isn't a bug on file for complete unification, please file one 
and cc: cls, jband, and me -- or tell me to do it.  Thanks.
...another XPCOM question I'm dumping on you, Edward.
Assignee: scc → kandrot
QA Contact: kandrot → scc
this bug's for you
Assignee: kandrot → jband
I'm not accepting this bug. Let's keep the xpcom bugs we're not targeting in the 
same bucket until someone *volunteers* to take them

FWIW... I think the question is: how much junk are you willing to have pulled 
into XPCOM_STANDALONE? The #ifdefs hold off intl. Pulling that in pulls in how 
much? Everything?

Also, don't forget about XPCONNECT_STANDALONE. It relies on the assumptions of 
XPCOM_STANDALONE and pulls in js and xpconnect while avoiding pulling in caps - 
and all that caps entails.
Assignee: jband → kandrot
Maybe this should be done the other way around and spin the INTL dependent 
stuff off into it's own component.

The biggest problem I am having trying to use the Mozilla code base in other 
projects is that most Moz components end up depending on every other component 
in Mozilla. For my projects I'd like to start with an XPCOM core and then add 
an XML parser or the GFX component if that's all I needed. 

For example I spent two days trying to figure out how to call Mozilla's XML 
parser from my code. I finally ended up building my own XML parser component.
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
I think this bug should become a tracking bug for making XPCOM standalone all
the time (not just with XPCOM_STANDALONE) - 

I think we're in agreement that there should be only one XPCOM, just like nspr. 

Basically we need to break two major dependencies: necko, which is used for url
parsing in nsLocalFile & friends, and uconv, which is used for a few string
manipulations.

 someone want to file new bugs? CC me and I'll help drive this (including doing
the engineering of actually breaking some of the dependencies)
Blocks: 100107
Status: NEW → ASSIGNED
Alec, here are the child bugs.  

XPCOM depends on necko for URL parsing:
http://bugzilla.mozilla.org/show_bug.cgi?id=100212

xpcom depends on uconv for doublebyte support:
http://bugzilla.mozilla.org/show_bug.cgi?id=100214
Depends on: 100212, 100214
Suddenly xpcom relies on the chrome registry too. cvsblame shows this to be 
racham's fix for a bugscape bug. http://bugscape/show_bug.cgi?id=4198.

I have an #ifndef XPCOM_STANDALONE patch that I'll attack. I'd like quick r/sr 
on it to get XPCOM and XPCONNECT standalone builds unbusted. And you need to 
factor this additional dependency into your thinking here.

Tell me that bugscape bug was well-filed (and not a bugzilla bug misplaced)!
Who reviewed and sr'd?  (I'm outside the firewall right now.)

Anyway, r/sr=brendan@mozilla.org on jband's patch here.

Cc'ing alecf, who may have dropped off this bug by mistake.

/be
> Tell me that bugscape bug was well-filed (and not a bugzilla bug misplaced)!
> Who reviewed and sr'd?  (I'm outside the firewall right now.)

Yeah, I'd say it belonged in bugscape - twisted webmail integration stuff. The 
bug has many patches. A couple of sr from mscott and a couple of r from 
ducarroz.
r=dougt.  but just to note, this is a workaround until the mail team fixes their
mess.
dougt: amen, brother -- these #ifdefs are all gonna die!  alecf's right, xpcom
should Be Like NSPR.

/be
I'll talk to bhuvan today. r=/sr=alecf if jband wants to check this in.. I hope
to have the bhuvan fix this today. :)
I checked in my workaround.
talked with bhuvan, he is backing out his changes today that caused the original
chrome dependency.
Depends on: 100676
Target Milestone: --- → mozilla1.0
Depends on: 107289
Keywords: meta
Summary: Why is XPCOM_STANDALONE needed? → Removing XPCOM_STANDALONE
Depends on: 107575
Depends on: 102943
Depends on: 110371
No longer depends on: 110371
Keywords: mozilla1.0
alec has been doing the bulk of the work on this bug.
Assignee: dougt → alecf
Status: ASSIGNED → NEW
So current status:
bug 100676 - nsLocalFile is the only guy we've got to fix now.
bug 102943 - caps & libjar dependency - no status, not sure how important this
is if we fix:
bug 107289 - since nobody actually uses the jar capability of xpcom, I'm
thinking we should either drop it or come up with a better way of plugging it in
so as not to have this dependency
bug 107575 - close.. I'm slowly untangling the string dependency
> bug 107289 - since nobody actually uses the jar capability of xpcom, I'm
> thinking we should either drop it or come up with a better way of plugging it in

Inasmuch as this relates to loading typelibs from zip/jar files, this is an
important feature. bug 46707 is about fixing up the packaging code to use this
feature and gain as much as 1/4meg of memory footprint win. We have a high
profile gecko embedder using this feture. So, "a better way of plugging it in"
is much prefered to dropping it.
Keywords: topembed
*sigh* so it looks like there's no way we can actually remove the
XPCOM_STANDALONE from the whole codebase. We can get very close though.
Our long poles right now are
bug 102943 - xpcom depends on libjar
bug 107289 - caps and libjar are mutually dependent

But mostly because of labor - nobody has time to work on them. Actually, if we
fixed bug 102943, it would make bug 107289 moot.
Target Milestone: mozilla1.0 → mozilla1.1
Keywords: mozilla1.0+
Keywords: mozilla1.0
No longer depends on: 100676
Depends on: 100676
minusing to topembed- as per edt triage.  not expected to block a particular
embedding customer.
Keywords: topembed → topembed-
we no longer care about the libjar/libcaps dependency (I'll move that to bug
100107) since bug 107289 was fixed. With that, we just have one more thing to fix:

http://lxr.mozilla.org/seamonkey/search?string=XPCOM_STANDALONE

which is just:
config.mak - can be yanked
nsLocalFileUnicode - not used anymore, should just be CVS removed.
PropertiesTest - should just be moved elsewhere, or removed from the system.

I'll clean those up in a patch coming up.
Status: NEW → ASSIGNED
No longer depends on: 102943
Priority: -- → P2
Target Milestone: mozilla1.1alpha → mozilla1.1beta
mozilla 1.1alpha already passed, just moving out to 1.1beta
moving tracking/non-critical bugs to mozilla 1.2
Target Milestone: mozilla1.1beta → mozilla1.2alpha
These are the last remenents of XPCOM_STANDALONE. Someone want to review?
(also removing the #ifdefs from PropertiesTest.cpp, forgot to include that in
the patch)

Comment on attachment 90798 [details] [diff] [review]
remove XPCOM_STANDALONE

r=dougt.

Great job.
Attachment #90798 - Flags: review+
Comment on attachment 90798 [details] [diff] [review]
remove XPCOM_STANDALONE

rs=brendan@mozilla.org, thanks.

/be
Attachment #90798 - Flags: superreview+
Attachment #90798 - Flags: approval+
Comment on attachment 90798 [details] [diff] [review]
remove XPCOM_STANDALONE

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
alright! No more XPCOM_STANDALONE!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 41385 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: