...as per suggested new guidelines, filing a bug to track branch landings. This bug will include build instructions. Some big branch tracking bug will depend on this bug (and others); this bug will be made to either depend on or perhaps block all the bugs that will be fixed by this landing.

This branch addresses at least the following bugs: #53065, #55143, #63923, #67876, #67961, #69872, #70075, #70077, #70078, #70082, #70142, #70337. Technically, this bug blocks those bugs; they're not fixed until this branch lands. But it's more useful if this bug depends on them, because then all the bugs this landing will fix are easy to isolate. ... so I'm using the dependency fields incorrectly. Does this hurt anybody? Comments appreciated.

Build Instructions: 0. Make sure these are the most recent instructions. 1. Pull as usual for building the trunk 2. Update mozilla/string to the branch tag STRING_081_BRANCH 3. Apply the patches in the 03/28/01 9:23 attachment http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2903 4. Build (be careful not to do a build that pulls, thus overwriting mozilla/string)

I just uploaded a release build of this branch for the Mac. I built it with the instructions above. It should appear shortly in the directory at http://ftp.mozilla.org/pub/mozilla/nightly/experimental/string/

Scott any update on builds for other platforms? mitchell

It took more time yesterday to produce and post an optimized Mac build than I had anticipated; but I expect to have a Windows build this evening and a Linux build shortly thereafter. When I post those builds, I will include an updated Mac build produced from the same sources.

The mac build has been smoketested by several volunteers and checks out OK. Awaiting additional platform builds.

Current status is (since this wasn't obvious in the comments above) this branch builds on Mac. Windows and Linux compilers are having trouble with the header organization and two of the remaining template classes. In my local tree, I believe I've reduced this down to just |nsPromiseConcatenation|. Should have that fixed by this evening. At which point, as I said earlier, I'll post fresh builds for all platforms.

So far, no known regressions (none reported in the Mac build; none expected).

I've checked in changes to the branch to make it compile on Windows and Linux. These changes require further patches outside of mozilla/string. Updated Build Instructions: 0. Make sure these are the most recent instructions. 1. Pull as usual for building the trunk 2. Update mozilla/string to the branch tag STRING_081_BRANCH 3. Apply the patches in the 03/30/01 5:28 attachment http://bugzilla.mozilla.org/showattachment.cgi?attach_id=29236 4. Build (be careful not to do a build that pulls, thus overwriting mozilla/string)

The bulk of the patches outside the tree are to prevent people from directly constructing non-|const| |nsPromiseFlat[C]Strings|. Here are excerpts showing the two basic changes (1) Call a (inline) function that produces a promise-flat, rather than declaring one yourself - result = docShellAsItem->SetName(nsPromiseFlatString(aName).get()); + result = docShellAsItem->SetName(PromiseFlatString(aName).get()); (2) Hold a |const| reference to a promise-flat, rather than a non-|const| instance - nsPromiseFlatString flat(aValue); + const nsPromiseFlatString& flat = PromiseFlatString(aValue); These changes are supported by the addition of the following routines in "nsPromiseFlatString.h" inline const nsPromiseFlatString PromiseFlatString( const nsAString& aString ) { return nsPromiseFlatString(aString); } inline const nsPromiseFlatCString PromiseFlatCString( const nsACString& aString ) { return nsPromiseFlatCString(aString); } This is the first non-transparent change in this branch. This change could be added to the trunk, before the branch lands, if necessary. And the individual patches related to this could land at the same time.

Leaf has scheduled release builds for Windows and Linux for me; external testers can play with the results over the weekend and if the results are acceptable, I'll get my carpool Monday.

Following the instructions here and applying the attached patch makes mozilla build on linux, check this puppy in! :-)

Odd, I didn't need this patch on a clean (+above steps) debug compile... It compiled fine, I'll test the build in a bit...

Alright, i'm going to try doing a linux release build today with the branch, and the last patch posted by scc (29378).

I hate to be a commie, but: nsCAimSession.cpp:738: no match for `nsAutoString & != const PRUnichar *&' ../../AIMGlue/COOL/Include/XprtDefs.h:167: candidates are: operator !=(const GUI D &, const GUID &) ../../AIMGlue/COOL/Include/XprtBstr.h:246: operator !=(const TBs tr &, const TBstr &) ../../AIMGlue/COOL/Include/XprtBstr.h:248: operator !=(const TBs tr &, const OLECHAR *) ../../AIMGlue/COOL/Include/XprtBstr.h:250: operator !=(const OLE CHAR *, const TBstr &) ../../dist/include/nsAString.h:613: operator !=(const nsAString &, const nsAString &) ../../dist/include/nsAString.h:721: operator !=(const nsACString &, const nsACString &) ../../dist/include/nsInt64.h:275: operator !=(const nsInt64 &, c onst nsInt64 &) ../../dist/include/nsTime.h:161: operator !=(const nsTime &, con st nsTime &) Jst, do you have a commercial tree to help a poor feeb out?

leaf: I think syd caught that one already... He said he was going to file a bug in bugscape about it and add a pointer to that here...

http://ftp.mozilla.org/pub/mozilla/nightly/2001-04-01-14-MSTRING_081_BRANCH/ warning, psm didn't get built (my fault, not scc's). Also, i can't get to my windows branch build machine, so that's going to be delayed somewhat (till tomorrow?)

Thanks for the help, Leaf :-) I _so_ can't wait to land this branch. I've been using my release Mac builds with the string changes for the past 5 days without incident.

did you build commercial on mac as well? I know i should be asking this with "leaf@netscape.com," but forget my hat-swapping... seems like the aim bustage is probably xp.

Syd built commercial for me; I can't even check out commercial since I'm not behind the firewall. If Syd's build isn't good enough, then with some effort I could get behind the firewall, but switching between the two connections is kind of painful.

Update: A mac build for testing can be found in http://ftp.mozilla.org/pub/mozilla/nightly/experimental/string/ Linux builds in http://ftp.mozilla.org/pub/mozilla/nightly/2001-04-01-14-MSTRING_081_BRANCH/ No regressions have been found as yet. Updated build instructions (the branch is currently known to build and run on all platforms): 0. Make sure these are the most recent instructions. 1. Pull as usual for building the trunk. 2. Update mozilla/string to the branch tag STRING_081_BRANCH. 3. Apply the patches in the 04/02/01 10:08 attachment http://bugzilla.mozilla.org/showattachment.cgi?attach_id=29458 4. Build, being careful not re-pull as part of your build, since that will overwrite the mozilla/string branch Still waiting on syd for the bug# of the bugscape bug that contains any fixes needed to build commercial.

leaf, scc: i get the same aim compilation error on linux using my "crack-baby" (gcc pre-3.0) compiler, without the string changes. i don't think that problem is relevant to this work.

I had already communicated with scc about the IM-related changes. Patch can be found in bugscape 4512

String branch has landed. After all the builds have cleared, I'll mark this bug fixed.

r=jst for STRING_081_BRANCH changes and the diffs in this bug.

r=jag for attach_id=29498

landed and cleared; marking fixed