Closed Bug 73786 Opened 23 years ago Closed 23 years ago

[tracking bug] land STRING_081_BRANCH

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: scc, Assigned: scc)

References

Details

Attachments

(6 files)

fixes needed outside of mozilla/string to land STRING_081_BRANCH
1.78 KB, patch
Details | Diff | Splinter Review
updated: files needed outside mozilla/string to compile STRING_081_BRANCH
21.68 KB, patch
Details | Diff | Splinter Review
Addtional change needed to make these changes compile on linux
1016 bytes, patch
Details | Diff | Splinter Review
updated: fixes needed outside mozilla/string to compile STRING_081_BRANCH, includes jst's patch (above) and some from pchen
23.75 KB, patch
Details | Diff | Splinter Review
updated: fixes needed outside mozilla/string to compile STRING_081_BRANCH
24.34 KB, patch
Details | Diff | Splinter Review
untemplatize some of the utility functions, intended to address speedracer bustage
9.51 KB, patch
Details | Diff | Splinter Review 
...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.
Blocks: 70090
Status: NEW → ASSIGNED
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.
Depends on: 53065, 55143, 63923, 67876, 67961, 69872, 70075, 70077, 70078, 70082, 70142, 70337
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
No longer depends on: 70082
No longer depends on: 69872
No longer depends on: 63923
landed and cleared; marking fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: