69854 - make string library compile stand-alone

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Scott Collins]

String currently has dependencies on allocation, |NS_ASSERTION|, types from
"prtypes.h", and possibly other cruft as well.  Although low priority for the
mozilla build itself, we would like string to build stand-alone for non-mozilla
clients.

Comment 1

[Scott Collins]

targeting mozilla 1.1, may pull in later if it becomes more important or seems
feasible

Comment 2

[Axel Hecht]

nscore.h is including prtypes.h and nsDebug.h (including nsCom.h).
Should we keep those? Getting rid of nsDebug.h would be fine, perhaps.
I suspect we only need string/src in standalone, and forget about obsolete
here?
nsMemory is just used once in AllocateStringCopy(), nsReadableUtils.cpp:150.
This looks in need for some fu. That impl. uses the UI thread to do some 
flushing (my fu goes down that drain), looks like a place to cut some "strings"

so much grep fu, better than just "adding myself to CC"

Axel

Comment 3

[Scott Collins]

re-targeting milestones, starting from a clean slate

Comment 4

[Scott Collins]

giving up ancient string bugs to the new string owner.  jag, you'll want to sort
through these and see which ones still apply and go with or against the
direction in which you intend strings evolve

Comment 5

[Benjamin Smedberg]

jag, I use the string libraries quite a bit in other applications, and I would
really like to see if it can not depend on XPCOM and NSPR dlls.  If you give me
direction, I would be glad to help with the coding.

Comment 6

[jag (Peter Annema)]

Benjamin: do you think we should still try to accomplish this?

Comment 7

[Benjamin Smedberg]

Not a chance.