diff --git a/README/mozilla/macbuild.htm b/README/mozilla/macbuild.htm index 96e036630e7..b4c49bfb6cf 100644 --- a/README/mozilla/macbuild.htm +++ b/README/mozilla/macbuild.htm @@ -1,875 +1,916 @@ + - - - MacFE Build Instructions - + MacFE Issues + + + + + +

MacFE Issues

-

-MacFE Build Instructions

-This is a general document on how to build, what works, what doesn't, and -things to watch out for when working on the Mac client. Please read -the entire document before you start tinkering...heck, you may just -learn something! +

A general document on how to build, what works, what doesn't, and +things to watch out for when working on the Mac client. Please +read the entire document before you start tinkering...heck, you +may just learn something!

+ +

Abbreviations you will probably see in this document:

-

Abbreviations you will probably see in this document:

    -
  • -MacFE - the Macintosh front end, including all the things you see -and some you don't.
    • +
  • MacFE - the Macintosh front end, including all the + things you see and some you don't.
    • + +
  • XP - cross platform back end code, mostly written in C. + You will see this used like, "This is an XP problem" which means + it's broken everywhere.
    • + +
  • MW - Metrowerks Corporation. They make our build tools + (CodeWarrior) and PowerPlant
    • + +
  • PP - PowerPlant, the GUI framework on which our app is + built
    • + +
  • CWProX - CodeWarrior Pro version X. You'll probably see + CWPro1, CWPro2, and CWPro3. We may also just refer to this as + CW.
    • + +
  • IDE - Integrated Development Environment. CodeWarrior + is an IDE.
    • + +
  • NC - the working name for our Aurora technology, the + Navigation Center.
    • + +
  • HT - HyperTree, a layer of XP APIs over RDF on which + the NavCenter is built.
    • +
-
  • -XP - cross platform back end code, mostly written in C. You will -see this used like, "This is an XP problem" which means it's broken everywhere.
    • +

    Building

    -
  • -MW - Metrowerks Corporation. They make our build tools (CodeWarrior) -and PowerPlant
    • +

    New 5.0 Features

    -
  • -PP - PowerPlant, the GUI framework on which our app is built
    • +

    Unfinished Features

    -
  • -CWProX - CodeWarrior Pro version X. You'll probably see CWPro1, -CWPro2, and CWPro3. We may also just refer to this as CW.
    • +

    Pitfalls

    -
  • -IDE - Integrated Development Environment. CodeWarrior is an IDE.
    • +

    History and Future

    -
    - -

    -Building

    - -

    -Pitfalls

    - -

    -History and Future

    +

    Help for parts of this document, especially build instructions, +was received from Dan Kogai.

    -
    Building

    +
    -

    -What are the minimum machine requirements?

    -To build Navigator, you need a fast PPC Mac. The faster the better. You -can't build with a 68K machine because we have too many resources, and -the build process will crash when trying to generate resources out of our -cross-platform strings. See the discussion below for a way around this. +Building -

    You will need about 96 MB of physical RAM to "fast link" the app. You -can still fast link if you give your machine 96 MB of virtual memory, but -then the VM hit is large enough to counteract any improvement. One of our -beta testers had a machine with only 64MB of physical RAM (VM was off) -and it ran out of memory trying to link. Turning VM on got it to link, -but build time increased greatly. +

    What are the minimum machine requirements?

    -

    The moral of the story: get lots of physical RAM and don't use VM. -

    -How big of a partition do I need for the source?

    -You should be ok with a 400MB disk partition, even when fully built. This -does not include tools like the IDE, just source. -

    -Why do I need CWPro2 or better?

    -We use CodeWarrior as our development environment at Netscape for the MacFE. -All of the projects and tools are geared towards the CodeWarrior IDE. In -addition, we make heavy use of PowerPlant and MSL which you can only get -from Metrowerks. +

    To build Navigator, you need a fast PPC Mac. The faster the +better. You can't build with a 68K machine because we have too many +resources, and the build process will crash when trying to generate +resources out of our cross-platform strings. See the discussion below +for a way around this.

    + +

    You will need about 96 MB of physical RAM to "fast link" the app. +You can still fast link if you give your machine 96 MB of virtual +memory, but then the VM hit is large enough to counteract any +improvement. One of our beta testers had a machine with only 64MB of +physical RAM (VM was off) and it ran out of memory trying to link. +Turning VM on got it to link, but build time increased greatly.

    + +

    Reports from the net indicate that the optimized version +(MozillaPPC) take much less RAM to build than the 96MB we suggest. If +you are running out of memory, try building that instead of the debug +version (the debug symbols require a lot of RAM come link time).

    + +

    The moral of the story: get lots of physical RAM and don't use +VM.

    + +

    How big of a partition do I need for the source?

    + +

    You should be ok with a 400MB disk partition, even when fully +built. This does not include tools like the IDE, just source.

    + +

    On an HFS+ volume, a full build takes about 110MB. HFS+ is good, +but utilities are sparse.

    + +

    Why do I need CWPro2 or better?

    + +

    We use CodeWarrior as our development environment at Netscape for +the MacFE. All of the projects and tools are geared towards the +CodeWarrior IDE. In addition, we make heavy use of PowerPlant and MSL +which you can only get from Metrowerks.

    + +

    While we say you need at least CWPro2, you may be able to get by +with Pro1, but probably not for very long. We haven't tested it, so +we don't recommend it. Get the upgrade. CodeWarrior kicks serious +butt!

    + +

    How do I setup my development environment?

    + +

    This part is very important--and somewhat difficult (especially +when compared to other platforms). I repeat: Read very carefully! +Once this part is done right, the build process itself should be as +easy as drag and drop.

    + +

    Here's a list of 3rd party software that we compile into +the application and where to get it:

    -

    While we say you need at least CWPro2, you may be able to get by with -Pro1, but probably not for very long. We haven't tested it, so we don't -recommend it. Get the upgrade. CodeWarrior kicks serious butt! -

    -How do I setup my development environment?

    -Here's a list of 3rd party software that we compile into the application -and where to get it: -Here's a list of other build tools that you need to install in order -to build and where to get them: + +

    Here's a list of other build tools that you need to install +in order to build and where to get them:

    +
      -
    • -MacPerl -5 MPW Tool
      • +
    • MacPerl + 5 MPW Tool
      • + +
    • MacPerl 5 Application
      • +
    • MakeStub - MPW (installed with CodeWarrior Heaven option). If + you choose not to install MPW, it is located on the MacOS Tools CD + in "CW Pro 2 Tools:CodeWarrior MPW:MPW:Tools"
      • + +
    • RunTSScript - in Mozilla source distribution + (mozilla:build:mac:RunTSScript), needs to be installed by hand
      • + +
    • ToolServer + - or in the CW distribution (CW Pro 2 Tools:Apple Development + Tools:ToolServer 3.4.1.sit). We recommend pulling it off the + CD because it comes with configuration files for CodeWarrior + which you would have to create manually were you to pull it off + the net.
      • -
    • -MakeStub - MPW (installed with CodeWarrior Heaven option). If you choose -not to install MPW, it is located on the MacOS Tools CD in "CW Pro 2 Tools:CodeWarrior -MPW:MPW:Tools"
      • +
    • New Alias MPW Tool + An MPW tool that creates Finder aliases for files. +
      • -
    • -RunTSScript - in Mozilla source distribution (ns:build:mac:RunTSScript), -needs to be installed by hand
      • - -
    • -ToolServer -- or in the CW distribution (CW Pro 2 Tools:Apple Development Tools:ToolServer -3.4.1.sit). We recommend pulling it off the CD because it comes -with configuration files for CodeWarrior which you would have to create -manually were you to pull it off the net.
      • - -
    • -ToolFrontEnd
      • - -
    • -patch -2.1
      • +
    • StreamEdit MPW Tool - MPW (installed with CodeWarrior Heaven option). If + you choose not to install MPW, it is located on the MacOS Tools CD + in "CW Pro 2 Tools:CodeWarrior MPW:MPW:Tools"
      • + + +
    • ToolFrontEnd
      • + +
    • patch + 2.1
    -Once you have all the pieces, here are the steps required to put everything -together: + +

    Once you have all the pieces, here are the steps required to put +everything together:

    +
      -
    1. -Install CodeWarrior from the CD. While it is large, installing the "CodeWarrior -Heaven" option will guarantee that you have everything you need. This will -give you PowerPlant, MSL, and MPW. If you choose to install less, proceed -at your own risk.
      2. - -
    2. -In the Finder, increase the memory partition of the IDE to 15MB (you can -get by with 12, if need be).
      3. - -
    3. -Download ToolFrontEnd. After expanding it, in "ToolFrontEnd Folder:Drop-Ins" -there are three items:
      4. - -
        -
      • -#include
        • - -
      • -ToolFrontEnd
        • - -
      • -ToolFrontEnd Panel
        • -
      -Create a folder named "Include Scanners". Place the file "#include" into -the Include Scanners folder. Move the Include Scanners folder to the CodeWarrior -Plugins folder. Create a folder named "ToolFrontEnd". Place the files "ToolFrontEnd" -and "ToolFrontEnd Panel" into the ToolFrontEnd folder. Place this folder -in the CodeWarrior Plugins folder. - -

      Open "ToolFrontEnd Panel" with ResEdit. Change the file type from 'Panl' -to 'PanL'. Save. -

    4. -Uncompress the StuffIt Archive for ToolServer. Place the ToolServer folder -in the same folder as your CodeWarrior environment (its actual placement -is not important). Create an alias from the Tools folder that lives in -the CodeWarrior MPW distribution and place it in the ToolServer folder. -Now ToolServer and MPW will share the same tool set and you only have to -maintain one tool repository.
      5. - -
    5. -After installing the MacPerl distribution (run the InstallerVISE application), -in the "MacPerl €" folder, there will be an MPW tool named "perl". Install -this in the same location as the rest of the MPW tools for ToolServer.
      6. - -
    6. -Install the "patch" and "MakeStub" MPW Tools in the same location. Note -that "MakeStub" is automatically installed by the "CodeWarrior Heaven" -install option.
      7. - -
    7. -Install RunTSScript (found in the Mozilla source distribution) in the compilers -folder in your build environment
      8. - -
    8. -Next, after downloading all the 3rd party software components, drag WASTE, -CWASTE, Menu Sharing, Mercutio, Internet Config, and the AEGizmo folders -(just as they are) into the "MacOS Support" folder in your build environment.
      9. - -
    9. -Start ToolServer from within CodeWarrior (or use MPW if you are brave enough). -We're about to patch some files. Make sure the ToolServer menu is in the -CodeWarrior menu bar by turning on the preference -under the "Extras" panel in the IDE Preferences (not the project preferences!). -The menu bar should look like this:
      10. - - -

      - -

      Choose "Start ToolServer" from the ToolServer menu (this is the icon -menu between "Window" and "Help" in the menubar above). You will now see -a window with no close box. This is your ToolServer Worksheet where you -will type (or cut & paste) the commands for the following steps. - -

      In case you have never used MPW/ToolServer before, the following is -very important. Pressing "return" does not execute commands like -you might think. It just inserts a newline into the worksheet like a normal -text editor. To actually get ToolServer to execute the command, you -must press "Enter" (lower right of numeric keypad). This executes the -line that the cursor is on, and only that line. If you want to execute -multiple lines at once, select them all and hit Enter. -

    10. -Set the shell variables {IDE} and {Source} to the correct paths for your -build environment. {IDE} is where your CodeWarrior IDE is located. {Source} -is the folder containing the toplevel "ns" folder of the Mozilla source. -Mine look like this (don't forget to keep the quotes if your path includes -spaces), yours will almost certainly be different:
      11. - -
      Set IDE "Develop:Source331 Build Environment:CW Pro 2:Metrowerks CodeWarrior:"
-Set Source "Source:FreeSource:"
      - -
    11. -If you are using CWPro2, execute the following lines to patch LDropFlag -to draw correcly over non-white backgrounds. You do not have to do this -if you are using Pro3 because it has been fixed.
      12. - -
      directory "{IDE}MacOS Support:PowerPlant:_In Progress:_Table Classes:"
-patch LDropFlag.cp "{Source}ns:lib:mac:patches:LDropFlag.patch"
-duplicate -y "{Source}ns:lib:mac:patches:DropFlag Icons.rsrc" "{IDE}MacOS Support:PowerPlant:PowerPlant Resources:"
      - -
    12. -Execute the following lines to patch menusharing.c to allow it to compile -with the new Universal Headers. It references an obsolete header file (GestaltEqu.h).
      13. - -
      directory "{IDE}MacOS Support:Menu Sharing Toolkit 4.1:"
-patch menusharing.c "{Source}ns:lib:mac:patches:menusharing.patch"
      - -
    13. -If you are using CWPro2 straight off the CD, you need to patch AppleEvents.r -to fix a problem with the Universal Headers (the definition of the 'aedt' -resource was omitted). You do not have to do this if you have applied -the netborne patch to Pro2 or are using Pro3 because it has been fixed.
      14. - -
      directory "{IDE}MacOS Support:Headers:Rez Headers:"
-patch AppleEvents.r "{Source}ns:lib:mac:patches:AppleEvents.r.patch"
      - -
    14. -You need to patch stat.mac.h to fix a problem in MSL where lines were omitted -(both CWPro2 and Pro3 share this problem)
      15. - -
      directory "{IDE}Metrowerks Standard Library:MSL C:MSL Mac:Public Includes"
-patch stat.mac.h "{Source}ns:lib:mac:patches:stat.mac.h.patch"
      - -
    15. -If you are using CWPro3, you have to unstuff and copy the old Grayscale -Appearance classes into the PowerPlant hierarchy. As of Pro3, they are -now obsolete and are located with the rest of the obsolete PowerPlant files. -We'll fix this shortly.
      16. +
    16. Install CodeWarrior from the CD. While it is large, installing + the "CodeWarrior Heaven" option will guarantee that you have + everything you need. This will give you PowerPlant, MSL, and MPW. + If you choose to install less, proceed at your own risk.
      17. + +
    17. In the Finder, increase the memory partition of the IDE to + 15MB (you can get by with 12, if need be).
      18. + +
    18. Download ToolFrontEnd. After expanding it, in "ToolFrontEnd + Folder:Drop-Ins" there are three items: + +
        +
      • #include
        • + +
      • ToolFrontEnd
        • + +
      • ToolFrontEnd Panel
        • +
      + +

      Create a folder named "Include Scanners". Place the file + "#include" into the Include Scanners folder. Move the Include + Scanners folder to the CodeWarrior Plugins folder. Create a folder + named "ToolFrontEnd". Place the files "ToolFrontEnd" and + "ToolFrontEnd Panel" into the ToolFrontEnd folder. Place this + folder in the CodeWarrior Plugins folder.

      19. + +
    19. Open "ToolFrontEnd Panel" with ResEdit. Change the file type + from 'Panl' to 'PanL'. Save.
      20. + +
    20. Uncompress the StuffIt Archive for ToolServer. The goal is to + let ToolServer and MPW share the same Tools directory so you don't + need to have multiple versions of tools. Do the following: + +
        +
      1. Open ToolServer's Tools folder. There is one file called + "RMetrowerks".
        2. + +
      2. Move RMetrowerks to Tools folder of MPW. MPW folder must be + at "Metrowerks:Codewarrior MPW:MPW" if you installed + Codewarrior Heaven.
        3. + +
      3. Remove ToolServer's Tools folder.
        4. + +
      4. Now create an alias of Tools folder in "CodeWarrior MPW" + and move it to your ToolServer folder. Rename the alias + (probably called "Tools alias") to "Tools"
        5. + +
      5. IMPORTANT: Make sure + you only have one instance of ToolServer on your machine. If + the build script finds the wrong one, the correct tools will + not be found and strange things will happen.
        6. +
      +
      21. + +
    21. After installing the MacPerl MPW Tool distribution (run the + InstallerVISE application), in the "MacPerl ƒ" folder, there + will be an MPW tool named "perl". Install this in MPW's tools + folder.
      22. + +
    22. Install the MacPerl Application (run the + InstallerVISE application). You can install this anywhere, but it is + recommended that you install it inside of your CodeWarrior folder for + easy reference. After installation, you will need to set a preference + to enable double-click launch of the perl scripts. This preference is set + by going under the Edit Menu to Preferences. Click on the "Script" button + and hit the radio button "Run Scripts opened from Finder"
      23. + +
    23. Install the "patch", "MakeStub", "NewAlias" and "StreamEdit" Tools in the tools + folder. Note that "MakeStub" and "StreamEdit" are automatically installed by the + "CodeWarrior Heaven" install option.
      24. + +
    24. Install RunTSScript (found in the Mozilla source distribution) + in the compilers folder in your build environment + ("Metrowerks:Metrowerks Codewarrior:Codewarrior + Plugins:Compilers")
      25. + +
    25. Next, after downloading all the 3rd party software components, + drag WASTE, CWASTE, Menu Sharing, Mercutio, Internet Config, and + the AEGizmo folders (just as they are) into the "MacOS Support" + folder in your build environment.
      26. + +
    26. Start ToolServer from within CodeWarrior (or use MPW if you + are brave enough). We're about to patch some files. Make sure the + ToolServer menu is in the CodeWarrior menu bar by turning on the + preference under the "Extras" panel in + the IDE Preferences (not the project preferences!). The menu bar + should look like this: + +

      + +

      Choose "Start ToolServer" from the ToolServer menu (this is the + icon menu between "Window" and "Help" in the menubar above). You + will now see a window with no close box. This is your ToolServer + Worksheet where you will type (or cut & paste) the commands + for the following steps.

      + +

      In case you have never used MPW/ToolServer before, the + following is very important. Pressing "return" does not + execute commands like you might think. It just inserts a newline + into the worksheet like a normal text editor. To actually get + ToolServer to execute the command, you must press "Enter" (lower + right of numeric keypad). This executes the line that the + cursor is on, and only that line. If you want to execute multiple + lines at once, select them all and hit Enter.

      27. + +
    27. Set the shell variables {IDE} and {Source} to the correct + paths for your build environment. {IDE} is where your CodeWarrior + IDE is located. {Source} is the folder containing the toplevel + "ns" folder of the Mozilla source. Mine look like this (don't + forget to keep the quotes if your path includes spaces), yours + will almost certainly be different (to + punctuate this, the things you need to change are in red). + + 
      Set IDE "Develop:Source331 Build Environment:CW Pro 2:Metrowerks CodeWarrior:"
+Set Source "Source:FreeSource:"
      28. + +
    28. If you are using CWPro2, execute the following lines to patch + LDropFlag to draw correcly over non-white backgrounds. You do + not have to do this if you are using Pro3 because it has been + fixed. + + 
      directory "{IDE}MacOS Support:PowerPlant:_In Progress:_Table Classes:"
+patch LDropFlag.cp "{Source}mozilla:lib:mac:patches:LDropFlag.patch"
+duplicate -y "{Source}mozilla:lib:mac:patches:DropFlag Icons.rsrc" "{IDE}MacOS Support:PowerPlant:PowerPlant Resources:"
      29. + +
    29. Execute the following lines to patch menusharing.c to allow it + to compile with the new Universal Headers. It references an + obsolete header file (GestaltEqu.h). + + 
      directory "{IDE}MacOS Support:Menu Sharing Toolkit 4.1:"
+patch menusharing.c "{Source}mozilla:lib:mac:patches:menusharing.patch"
      30. + +
    30. If you are using CWPro2 straight off the CD, you need to patch + AppleEvents.r to fix a problem with the Universal Headers (the + definition of the 'aedt' resource was omitted). You do not have + to do this if you have applied the netborne patch to Pro2 or are + using Pro3 because it has been fixed. + + 
      directory "{IDE}MacOS Support:Headers:Rez Headers:"
+patch AppleEvents.r "{Source}mozilla:lib:mac:patches:AppleEvents.r.patch"
      31. + +
    31. You need to patch stat.mac.h to fix a problem in MSL where + lines were omitted (both CWPro2 and Pro3 share this problem) + + 
      directory "{IDE}Metrowerks Standard Library:MSL C:MSL Mac:Public Includes"
+patch stat.mac.h "{Source}mozilla:lib:mac:patches:stat.mac.h.patch"
      32. + +
    32. If you are using CWPro3, you have to unstuff and copy the old + Grayscale Appearance classes into the PowerPlant hierarchy. As of + Pro3, they are now obsolete and are located with the rest of the + obsolete PowerPlant files. We'll fix this shortly.
      33. + +
    33. Congratulations! Now you are ready to build. Once these steps + are done, you don't have to repeat these setups the next + time!
    -

    -Ok, so how do I build?

    -There is an AppleScript called BuildList located in ns:cmd:macfe:projects. -This droplet takes, as input, a text file which lists the projects in the -order which they are to be built. This allows us to build different versions -of the product just by dropping a different "script" on BuildList (such -as Debug, Optimized, Navigator stand-alone, or navigator + composer). +

    Ok, so how do I build?

    +

    In the folder mozilla:build:mac:, there are several Perl scripts with +names of the form BuildMozillaXXX.pl, where XXX is "Optimized", +"Debug", "Tinderbox", et al. Each script builds the corresponding +version of Mozilla. If you configured the MacPerl application to +execute scripts that are opened from the finder, all you have to do is +double click on the appropriate one; otherwise, launch MacPerl, and +run the appropriate script from the "Run Script..." menu item.

    -

    These scripts are located in mozilla:cmd:macfe:projects:client and have names -like BuildMozPPCDebugList.txt. This script will build a debug version -of Mozilla (navigator + composer) for PPC. Get it? Good. All you have to -do is drag this script to the BuildList droplet and watch it crunch away. -Now go out to dinner. By the time you get back, you should have an executable -in ns:cmd:macfe:projects:client called, for this particular script, MozillaPPCDebug. -You will see the following build lists in the client folder, but as of -3/31, only BuildMozPPCList.txt and BuildMozPPCDebugList.txt are guaranteed -to work: -

      -
    • -BuildMozPPCList.txt
      • +

      These `configured build' scripts are simple, and you might want to +make your own to force your build to StopForErrors(), or alternatively +DontStopForErrors(), et al. You can set up certain build-script +variables and (soon) compile-time flags. Compare the supplied scripts +to figure out what you might want. Note that CodeWarriorLib, Moz.pm, +and BuildList.pm, are AppleScript libraries and Perl modules meant to +be used by a `configured build'. Use your favorite POD viewer (Shuck +comes with MacPerl) to view the documentation in the Perl scripts.

      -
    • -BuildMozPPCDebugList.txt
      • +

      If there were any errors in any of the projects along the way, the +script will stop at that point and the IDE will tell you the errors. +You can fix them and make sure they current project builds, but to +continue the automation, you have to start from the beginning by +double-clicking the script again. This isn't quite as bad as it +sounds because the previous projects are already built (unless you +changed some major header file). Please note that stopping the script +once it has started is difficult. We are working to address +this issue.

      -
    • -BuildNavPPCDebugList.txt [ might work ]
      • +

      After the build is complete, you can find aliases to the built libraries +and the final Mozilla application. Debug builds are built to +Mozilla:dist:client_debug, while optimized builds are built to Mozilla:dist:client. +

      -
    • -BuildNavPPCList.txt [ might work ]
      • -
    -If there were any errors in any of the projects along the way, the script -will stop at that point and the IDE will tell you the errors. You can fix -them and make sure they current project builds, but to continue the automation, -you have to start from the beginning by dropping the script onto BuildList. -This isn't quite as bad as it sounds because the previous projects are -already built (unless you changed some major header file). +

    Don't worry too much about the numerous warnings generated during +the build. We try our best to get the XP teams to use real compilers, +but alas, they continue to write warning-laden code. There is also +some generated code (Java is one example) that has a lot of warnings +that we can't help either. If you write any new code, please help us +in our quest to get zero warnings.

    -

    Don't worry too much about the numerous warnings generated during the -build. We try our best to get the XP teams to use real compilers, but alas, -they continue to write warning-laden code. There is also some generated -code (Java is one example) that has a lot of warnings that we can't help -either. If you write any new code, please help us in our quest to get zero -warnings. -

    -How long does it take to build?

    -On a G3 with the source and IDE on a RAM disk, it takes about 25 minutes. -On a PowerTowerPro 225 and everything on the hard drive, it takes about -45mins to an hour. On a 9500/132 it takes over 2 1/2 hours. +

    How long does it take to build?

    -

    The moral of the story: Don't try this on your 6100/66. -

    -What's special about running the debug build?

    -Running the optimized (non-debug) version is easy, just double-click it -and it will work. This is because all the shared libraries are compiled -directly into the application. We don't do this with the debug version -to facilitate changing bits in projects other than the main one. This way, -you don't have to relink the entire app (which can take a while) to see -the changes, just the project that was modified. +

    On a G3 with the source and IDE on a RAM disk, it takes about 25 +minutes. On a PowerTowerPro 225 and everything on the hard drive, it +takes about 45mins to an hour. On a 9500/132 it takes over 2 1/2 +hours.

    -

    As a result, you have to find a way to get all the shared libraries -from where they are built (scattered throughout the tree) into the same -folder as the app so CFM can find them. Luckily, the BuildList script will -create all these aliases for you and put them in the right places! +

    The moral of the story: Don't try this on your 6100/66.

    -

    Another nicety about the debug build is that there is a special "trace" -function which can be used to display messages about the state of the application -as it runs through certain blocks of code. To see these messages (since -the Mac doesn't have stdout or stderr) you need to run an application called -TraceMonitor. << where do we distribute this???!?>> -

    -How do I build a 68K version?

    -For now, you can't. The projects have not been kept up to date and aren't -even in the tree anymore. If you would like to create them and get all -the exports right with CFM-68K, go right ahead. We will be so happy! -

    -Why use IDE_Options.h when all that is in the project file?

    -It was originally intended to make sure that all 300 of us at Netscape -are using the same environment and compilation flags. If something gets -turned on/off by accident in the project prefs, it can introduce a subtle -bug that can take days to track down for naught. Having a file that specifies -exactly what flags should be used guarantees that this can't happen. +

    From Dan Kogai:

    + +
    It took me 70 minutes to build Mozilla Debug with + configurations below; + +

    PowerMac 7600/120
    + 192MB RAM (No VM)
    + 1 + 4 GB HD (No RAM Disk)
    + MacOS 8.1
    + CWPro2
    + HFS+

    + +

    What's special about running the debug build?

    + +

    Running the optimized (non-debug) version is easy, just +double-click it and it will work. This is because all the shared +libraries are compiled directly into the application. We don't do +this with the debug version to facilitate changing bits in projects +other than the main one. This way, you don't have to relink the +entire app (which can take a while) to see the changes, just the +project that was modified.

    + +

    As a result, you have to find a way to get all the shared +libraries from where they are built (scattered throughout the tree) +into the same folder as the app so CFM can find them. Luckily, the +BuildList script will create all these aliases for you and put them +in the right places!

    + +

    Another nicety about the debug build is that there is a special +"trace" function which can be used to display messages about the +state of the application as it runs through certain blocks of code. +To see these messages (since the Mac doesn't have stdout or stderr) +you need to run an application called TraceMonitor. TraceMonitor is +available through Apple Computer with the ASLM package. +

    + +

    How do I build a 68K version?

    + +

    For now, you can't. The projects have not been kept up to date and +aren't even in the tree anymore. If you would like to create them and +get all the exports right with CFM-68K, go right ahead. We will be so +happy!

    + +

    Why use IDE_Options.h when all that is in the project file?

    + +

    It was originally intended to make sure that all 300 of us at +Netscape are using the same environment and compilation flags. If +something gets turned on/off by accident in the project prefs, it can +introduce a subtle bug that can take days to track down for naught. +Having a file that specifies exactly what flags should be used +guarantees that this can't happen.

    + +

    Now that we move to net development, I'm sure you will agree that +this is even more important.

    -

    Now that we move to net development, I'm sure you will agree that this -is even more important.

    -
    New 5.0 Features

    -We can't present this section until after 3/31/98. Please check back here -after that.  +

    -
    Unfinished "Features"

    -We can't present this section until after 3/31/98. Please check back here -after that.  + +

    General FE Problems

    + +
      +
    • DNS lookups may hang up the machine for up to a minute. + Don't worry, your mac did not freeze!
      • + +
    • FTP doesn't work quite right. URLs typed into the location bar + will not load and the MIME mappings (save to disk, etc) are broken + so everything is loaded into the browser window instead of saving + to disk.
      • + +
    • frame around current tab group broken
      • + +
    • tabbing around to text entry areas and back to the Location + field is broken
      • + +
    • can't drag from Navigator when app is in background
      • + +
    • Folders on personal toolbar. Sigh, unless we can rewrite the + bookmarks menu code, we just don't have enough hierarchical menu + id's to put menus on personal toolbar folders. They still act as + drop sites, so you can drop urls into them but clicking on them + will just beep.
      • + +
    • Printing is....sub-optimal.
      • + +
    • "Mariner" layout improvements are nice, but on very + complicated pages the machine will hang for a few seconds while it + is relaying out the page. This can last 4-6 seconds sometimes. + This really looks bad when the NavCenter shelf is sliding out + during a drag and drop. If you are patient enough, you will be + rewarded, but it is slow.
      • +
    +

    -
    Pitfalls

    -There are a couple of pitfalls that we have to keep straight when it comes -to editing resources. -

    -Why do I keep getting messages about unknown custom types in Constructor?

    -For starters, make sure you have an alias to the following two files in -your Constructor folder: +
    + +Pitfalls + +

    There are a couple of pitfalls that we have to keep straight when +it comes to editing resources.

    + +

    Why do I keep getting messages about unknown custom types in +Constructor?

    + +

    For starters, make sure you have an alias to the following two +files in your Constructor folder:

    +
      -
    • -ns:cmd:macfe:rsrc:CrossProduct:Mozilla_Custom_CPPbs
      • - -
    • -ns:cmd:macfe:rsrc:Communicator:MailNewsCppbs.cnst
      • -
    -You may have to explicitly open these files up while running Constructor -to be able to see the new types, especially for the ones in MailNewsCppbs.cnst. -Not sure why yet. - -

    For editing other kinds of resources, we have a TMPL file for ResEdit/Resourcerer. -Place these in the appropriate location for your resource editor -

      -
    • -ns:cmd:macfe:rsrc:CrossProduct:Mozilla_Custom_TMPLs
      • - -
    • -ns:cmd:macfe:rsrc:CrossProduct:Other_Comm_TMPLS.rsrc
      • +
    • mozilla:cmd:macfe:rsrc:CrossProduct:Mozilla_Custom_CPPbs
      • + +
    • mozilla:cmd:macfe:rsrc:Communicator:MailNewsCppbs.cnst
    -

    -Why don't my toolbar buttons work anymore in the browser window?

    -Because of the way we have the toolbars as CIncludeViews (which work in -a similar way to #include in C/C++), the RidL will be messed up if you -edit the main browser window PPob. Constructor regenerates this list based -on all the controls that are in the view when you save, but because we -use CIncludeView, the toolbar buttons aren't actually in the view so the -RidL is empty. They will still show up when you build, but they won't do -anything because they are not registered with the browser window. Until -we fix this, just use Resourcer to replace the incorrectly generated one -with an old version. The old version is about 58 bytes long and the new -one is about 10 so you should be able to easily tell which is which. -

    -Why are there so many damn resources?

    -As you may have noticed, we've got too many damn resources. Most of them -are 'STR ' resources which are generated at build time and contain all -of our cross-platfrom strings. We would like to generate these resources -more intelligently (into 1/10 the number of 'STR#' resources maybe) but -ran out of time before the source had to go out. Before you rush out and -change it for us, stop! There are some constraints on the final -solution, mostly to do with i18n and l10n being able to leverage existing -work on older product to do new products. If you want to help us out with -this, please send us some email and we can have out i18n team talk with -you to make sure it gets done correctly! -

    -Why doesn't it work better with Internet Config?

    -For starters, the main reason why we never drank the IC kool-aid was that -there was no support for multiple profiles. Being one of the main features -which our competition did not have, we thought this was pretty important. -There are rumblings in the IC world that IC 2.0 will support multiple profiles. -Great! That still leaves us with the second reason: there are many, many, -many preferences that we use that are not reflected in IC. As a result, -we already have to maintain prefs for those that are not covered by IC -so we can't be totally IC dependent. +

    You may have to explicitly open these files up while running +Constructor to be able to see the new types, especially for the ones +in MailNewsCppbs.cnst. Not sure why yet.

    -

    Of course, now that the source is free, maybe we can drive the direction -of IC to include all of our wacky networking prefs. -

    -Where are all my old 4.0X bookmarks and prefs?

    -In the process of getting the source ready for distribution, we removed -all mentions of "Netscape" from the product. As you may know, the 4.0X -preferences are stored in a folder called "Netscape Users." Well, that -folder is now called "Navigator Users" and the preference file is now called -"Navigator Preferences" instead of "Netscape Preferences." +

    For editing other kinds of resources, we have a TMPL file for +ResEdit/Resourcerer. Place these in the appropriate location for your +resource editor

    -

    It's probably best not to use any of your old prefs at this point since -some of them rely on security calls that are no longer in the free source -product. After you create a new profile (and you will have to when you -start the free source), copy your bookmarks.html file from your old profile -into the new user profile folder and replace the empty one that's already -there (if there is one). +

      +
    • mozilla:cmd:macfe:rsrc:CrossProduct:Mozilla_Custom_TMPLs
      • + +
    • mozilla:cmd:macfe:rsrc:CrossProduct:Other_Comm_TMPLS.rsrc
      • +
    -

    For your old bookmarks to be seen, you must throw away the "NavCntr" -folder created in your new profile folder. After you do that bookmarks -will be imported into Aurora automagically. Note that changes that you -make to your bookmarks in 5.0 will not (as of today) be written back to -the Bookmarks.html file, but instead are stored in a database within the -"NavCntr" folder. If anything gets corrupted in the NavCenter, you can -always throw this folder into the trash and your original bookmarks will -be reimported. +

    Why don't my toolbar buttons work anymore in the browser +window?

    + +

    Because of the way we have the toolbars as CIncludeViews (which +work in a similar way to #include in C/C++), the RidL will be messed +up if you edit the main browser window PPob. Constructor regenerates +this list based on all the controls that are in the view when you +save, but because we use CIncludeView, the toolbar buttons aren't +actually in the view so the RidL is empty. They will still show up +when you build, but they won't do anything because they are not +registered with the browser window. Until we fix this, just use +Resourcer to replace the incorrectly generated one with an old +version. The old version is about 58 bytes long and the new one is +about 10 so you should be able to easily tell which is which.

    + +

    Why are there so many damn resources?

    + +

    As you may have noticed, we've got too many damn resources. Most +of them are 'STR ' resources which are generated at build time and +contain all of our cross-platfrom strings. We would like to generate +these resources more intelligently (into 1/10 the number of 'STR#' +resources maybe) but ran out of time before the source had to go out. +Before you rush out and change it for us, stop! There are some +constraints on the final solution, mostly to do with i18n and l10n +being able to leverage existing work on older product to do new +products. If you want to help us out with this, please send us some +email and we can have out i18n team talk with you to make sure it +gets done correctly!

    + +

    Why doesn't it work better with Internet Config?

    + +

    For starters, the main reason why we never drank the IC kool-aid +was that there was no support for multiple profiles. Being one of the +main features which our competition did not have, we thought this was +pretty important. There are rumblings in the IC world that IC 2.0 +will support multiple profiles. Great! That still leaves us with the +second reason: there are many, many, many preferences that we use +that are not reflected in IC. As a result, we already have to +maintain prefs for those that are not covered by IC so we can't be +totally IC dependent.

    + +

    Of course, now that the source is free, maybe we can drive the +direction of IC to include all of our wacky networking prefs.

    + +

    Where are all my old 4.0X bookmarks and prefs?

    + +

    In the process of getting the source ready for distribution, we +removed all mentions of "Netscape" from the product. As you may know, +the 4.0X preferences are stored in a folder called "Netscape Users." +Well, that folder is now called "Navigator Users" and the preference +file is now called "Navigator Preferences" instead of "Netscape +Preferences."

    + +

    It's probably best not to use any of your old prefs at this point +since some of them rely on security calls that are no longer in the +free source product. After you create a new profile (and you will +have to when you start the free source), copy your bookmarks.html +file from your old profile into the new user profile folder and +replace the empty one that's already there (if there is one).

    + +

    For your old bookmarks to be seen, you must throw away the +"NavCntr" folder created in your new profile folder. After you do +that bookmarks will be imported into Aurora automagically. Note that +changes that you make to your bookmarks in 5.0 will not (as of today) +be written back to the Bookmarks.html file, but instead are stored in +a database within the "NavCntr" folder. If anything gets corrupted in +the NavCenter, you can always throw this folder into the trash and +your original bookmarks will be reimported.

    + +

    Also note that these new bookmarks and preferences are totally +separate from your 4.0X prefs.

    -

    Also note that these new bookmarks and preferences are totally separate -from your 4.0X prefs.

    -
    History and Future

    +
    + +History and Future + +

    History

    + +

    Excuse me while I ramble...

    -

    -History

    -Excuse me while I ramble...
      -
    • -Built using Metrowerks PowerPlant, the client has been PPC native from -day one. 68K support was dropped in 5.0 due to the high cost of maintenance. -Any takers?
      • - -
    • -Mail/News was added in 2.0 and Composer was added in 3.0 (called Navigator -Gold). Both were dramatically improved with 4.0.
      • - -
    • -Java came to the Mac in 3.0, even though Windoze and unix had it in 2.0.
      • - -
    • -Multi-byte language support for inline edit fields added in 4.0
      • - -
    • -The preferences used to be STR# resources. Now they are done in javascript.
      • - -
    • -Because of the sheer number of resources (and the "theoretical limit" on -the number of resources in a file imposed by the Resource manager -- which -we still exceed on a daily basis), a number of strings and icons were moved -out of the main application and into a file called "Netscape Resources" -in 4.0
      • - -
    • -For plain-text email/form composition, we used VText up through 4.0. For -5.0, we switched to WASTE because of its minimal impact on the PowerPlant -hierarchy. VText caused us fits every time we wanted to upgrade to a newer -version of PowerPlant because it wrapped its tentacles around every limb -of PowerPlant.
      • - -
    • -4.0 included a new memory management scheme which drastically reduced the -amount of memory used by the client. This is why the memory partition of -4.0 is about half of 3.0.
      • - -
    • -A version of Navigator sans Mail/News/Composer debuted with 4.03, and again -two days later with 4.03.1.
      • +
    • Built using Metrowerks PowerPlant, the client has been PPC + native from day one. 68K support was dropped in 5.0 due to the + high cost of maintenance. Any takers?
      • + +
    • Mail/News was added in 2.0 and Composer was added in 3.0 + (called Navigator Gold). Both were dramatically improved with + 4.0.
      • + +
    • Java came to the Mac in 3.0, even though Windoze and unix had + it in 2.0.
      • + +
    • Multi-byte language support for inline edit fields added in + 4.0
      • + +
    • The preferences used to be STR# resources. Now they are done + in javascript.
      • + +
    • Because of the sheer number of resources (and the "theoretical + limit" on the number of resources in a file imposed by the + Resource manager -- which we still exceed on a daily basis), a + number of strings and icons were moved out of the main application + and into a file called "Netscape Resources" in 4.0
      • + +
    • For plain-text email/form composition, we used VText up + through 4.0. For 5.0, we switched to WASTE because of its minimal + impact on the PowerPlant hierarchy. VText caused us fits every + time we wanted to upgrade to a newer version of PowerPlant because + it wrapped its tentacles around every limb of PowerPlant.
      • + +
    • 4.0 included a new memory management scheme which drastically + reduced the amount of memory used by the client. This is why the + memory partition of 4.0 is about half of 3.0.
      • + +
    • A version of Navigator sans Mail/News/Composer debuted with + 4.03, and again two days later with 4.03.1.
    -

    -Future

    -There is certainly a lot to do. In order to not duplicate too much work -(since we are still working on this full time here at Netscape), I've put -together a list of what we plan on doing and what we want to do but probably -won't get around to because of time constraints. +

    Future

    + +

    There is certainly a lot to do. In order to not duplicate too much +work (since we are still working on this full time here at Netscape), +I've put together a list of what we plan on doing and what we want to +do but probably won't get around to because of time constraints.

    + +

    Things that we are going to focus on:

    -

    Things that we are going to focus on:

      -
    • -More NavCenter work
      • - -
    • -Solve the issues with too many 'STR ' resources (see note on issues -page)
      • - -
    • -Modularization (HTML display isolated from networking, etc)
      • - -
    • -use new Appearance Manager classes in PowerPlant
      • - -
    • -Navigation Services (new open/save dialogs in Allegro) support. We have -an ancient SDK and have integrated it in a few places, but the current -implemenation that we have doesn't work very well. It's cool, though.
      • - -
    • -More drag and drop in composer.
      • - -
    • -More support for Internet Config (see note on issues -page).
      • - -
    • -external Java VM support (MRJ, etc)
      • +
    • More NavCenter work
      • + +
    • Solve the issues with too many 'STR ' resources (see note on + issues page)
      • + +
    • Modularization (HTML display isolated from networking, + etc)
      • + +
    • use new Appearance Manager classes in PowerPlant
      • + +
    • Navigation Services (new open/save dialogs in Allegro) + support. We have an ancient SDK and have integrated it in a few + places, but the current implemenation that we have doesn't work + very well. It's cool, though.
      • + +
    • More drag and drop in composer.
      • + +
    • More support for Internet Config (see note on issues + page).
      • + +
    • external Java VM support (MRJ, etc)
    -Things we would like some help on: + +

    Things we would like some help on:

    +
      -
    • -printing support
      • - -
    • -68K version
      • - -
    • -Context Menu Manager support
      • - -
    • -bug fixes of any kind
      • - -
    • -performance tuning of any kind
      • - -
    • -getting around the limitation of 255 hierarchical menus imposed by the -OS. This would let us do a "real" personal toolbar with folders that have -popup menus.
      • - -
    • -Fixing the build system so it uses makefiles without having to give up -the CW IDE for source browsing/editing.
      • - -
    • -better publishing in Composer
      • - -
    • -add NavCenter to Composer window
      • - -
    • -better table editing in Composer
      • +
    • printing support
      • + +
    • 68K version
      • + +
    • Context Menu Manager support
      • + +
    • bug fixes of any kind
      • + +
    • performance tuning of any kind
      • + +
    • getting around the limitation of 255 hierarchical menus + imposed by the OS. This would let us do a "real" personal toolbar + with folders that have popup menus.
      • + +
    • Fixing the build system so it uses makefiles without having to + give up the CW IDE for source browsing/editing.
      • + +
    • better publishing in Composer
      • + +
    • add NavCenter to Composer window
      • + +
    • better table editing in Composer
    -
    Mike Pinkerton (pinkerton@netscape.com)
    - -
    -
    -
    Copyright © 1998 Netscape -Communications Corporation
    +
    +Mike Pinkerton (pinkerton@netscape.com) +