Closed Bug 7791 Opened 25 years ago Closed 25 years ago

exorcise lib/xp

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: waterson, Assigned: alecf)

References

Details

This is a bunch of old pre-5.0 stuff that is duplicated elsewhere in the
product.
I did some work to get rid of XP_QSORT and use NS_QuickSort and someone from the
net did the work to switch everything else over to NS_QuickSort, but I think
XP_QSORT is still being built in from lib/xp/xp_sort.c
Status: NEW → ASSIGNED
Target Milestone: M8
I'm horrified to see things like fe_proto.h still in use, but akkana will save
us after M7.  I'll file separate bugs and roll them up with a big one that
depends on all the "why are we using old MozillaClassic cruft" bugs.

/be
*** Bug 8731 has been marked as a duplicate of this bug. ***
Need Necko, so M9.

/be
Target Milestone: M8 → M9
What is the necko dependency here? Is someone using net.h for something?
Target Milestone: M9 → M10
I'm gonna do this, just not by M9's deadline.  I don't want it to linger, so
I'll push hard in M10 and get this stuff obsoleted or migrated elsewhere and
XPCOMified as appropriate.

/be
Assignee: brendan → alecf
Status: ASSIGNED → NEW
alecf kindly says he's doing this.  Alec, dp and/or dveditz were gonna move
xp_regexp.[ch] to xpcom/ds/nsWildCard.{cpp,h}, fixing the misnomer and making
the code a C++ XPCOM utility thing.  Dunno if there was a plan to make an
interface and component too -- dp, dan?

/be
*** Bug 8784 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M10 → M11
one comment about these routines - they are ONLY used by libjar right now.

I'll make them into a service while I'm at it.
If libjar is the only one we could just move it in there. When we started using
it it was also in use by netlib (pre-Necko).

These are useful globbing routines, expecially in the absense of an
easy-to-get-to regexp from JS. XPCOM/IO is one possible place for them if we
want them shared, xpcom/ds with the string stuff would be another place.
*please* preserve it as an extern "C" API.

Libjar really wants them as a static library because we'd like to use the
routines from the install wizards which won't have the benefit of XPCOM.
I wasn't going to REMOVE the C++ bindings, just make a service out of them
But if nobody else needs them I'd rather move them into libjar to reduce xpcom
bloat. So that's what I'll do.
almost done.
unix and mac are completely done, and libxp has been removed from the build.
windows still has one or two more windows-specific libraries.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
[15:25:10] <alecf> libxp is, now, finally, officially, dead
Component: XP Miscellany → XPCOM
You need to log in before you can comment on or make changes to this bug.