In June, I made a branch which did the build using CW7 EA, XML projects, and no ToolServer. At this point, the branch is probably too old to merge and significant changes have been made to the build scripts in the meanwhile. I'll use this bug as a placeholder for various patches: (1) Changes to the build scripts which can be checked before the switch to automatically update CW projects. (2) Changes to the code which allow it to compile with the new compiler (which is more strict) but should compile with the current compiler as well.

-> after 6.2 RTM

Putting these here for safe-keeping and for potential usefulness to others. These changes, by having build flags UPDATE_PROJECTS and BUILD_PROJCTS, allow you to, by defining UPDATE_PROJECTS in build prefs, to go through the tree and automatically update all projects to the latest CW. This was possible by hacking CodeWarriorLib.pm to have an open_project routine which takes a param telling whether to update the project on opening it. open_project, since it returns a reference to the project, has other uses as well. If we had a build_target routine, the IDL projects could be built by doing: $my(p) = open_project() build_target($p, headers) build_target($p, xpt) close_project($p) Then, without doing the "leave projects open" bit, IDL projects would probably build faster this way.

Plan of attack: 1. Use the build script patches here to automatically update all projects in the tree to Pro 7. (Done) 2. Get the build to work. At this point, I'll post a tree-wide patch here and an archive of projects which needed manual changes. (In progess today) 3. Use the build scripts to export all of the now working .mcp projects to XML 4. Check in the XML files 5. Flip the switch in the build scripts.

Don't forget to look at some of my old CW6 bugs if you find problems. Search the summary field for CW6 and follow the dependencies, including the "fixed" ones. (many of them were WONTFIX as we skipped CW6 and some assumed there wouldn't be the same problems in 7. Given most of the issues where ANSI compliance, I think that's optimisitic) Now would be a good time to fix bug 40013 and 40100 too, if you're cleaning up the build system. Actually 40100 is a blocker for this as CW7 won't build because of it. Might save you some time...

This bug obsoletes bug 40100 and bug 53679. Both of those issues are being dealt with here. I suggested those bugs be closed but I'll clear the dependency anyway. Also, bug 40013 has been incorporated (thanks!).

*** Bug 53679 has been marked as a duplicate of this bug. ***

*** Bug 40100 has been marked as a duplicate of this bug. ***

*** Bug 40013 has been marked as a duplicate of this bug. ***

How sad - I have a patch for the whole tree but bugzilla is not letting me post it right now. I'll try in the morning.

Here's the list of changed projects: xpidl.mcp Interface.mcp MemAllocator.mco NSRuntime.mcp NSStdLib.mcp xpcomPPC.mcp gfx.mcp widget.mcp PowerPlant.mcp PPBrowser.mcp I have built (under OS X) and run the CarbonDebug build. Still to do: (1) the three other builds (classic, opt, etc.) (2) churn out the XML files - easy and automated (3) check in the 210 XML projects

Conrad, while you're touching NSRuntime.mcp, could you fix the profiling targets too? They're currently misnamed, they're named NSRuntime[Carbon]Profil.shlb but they generate a debug library. I suggest we name them NSRuntime[Carbon]ProfileDebug.shlb and add optimized targets too.

I think the reason they're misnamed, or the names are truncated, is because the 31 char file name limit. It should be possible to have a target name > 31 chars though(?) I'll check it out.

Comment on attachment 53251 [details] [diff] [review] tree-wide patch to text files Conrad: one hunk fails in object.c, I looked and its trying to change the CVS tag embeded in the file. I take it this was accidental?

Problems with this patch: 1/ From the CodeWarrior SDK library notes: "The Mac OS shared libraries in this folder are provided for linking purposes only. The actual library implementations are merged into the 4.2.5 IDE. So, when testing your plugins you should not copy the MWMacOSCOM.shlb or PluginLib4.shlb into your CodeWarrior installation. Likewise, you should not merge these libraries into your plugins." I think this means we ought to alter out build instructions to tell people to leave the "(CodeWarrior SDK)" folder where it is (in the top level of the CodeWarrior install) and simply add Compiler Relative access paths for the "libraries" and "headers" folders to xpidl.mcp. AFAICT the Panels, Linker and Compiler targets need to be changed. 2/ The project still includes PluginLib4, which no longer exists. Should be linking against instead PluginLib4.shlb I think...

:( Currently blowing up in MemAllocator... probably fairly simple to fix, will try later: Error : ambiguous access to overloaded function 'malloc(unsigned long)' 'std::malloc(unsigned long)' nsAllocatorManager.cp line 716 newBlock = ::malloc(newSize); Error : ambiguous access to overloaded function 'free(void *)' 'std::free(void *)' nsAllocatorManager.cp line 723 ::free(block); Error : ambiguous access to overloaded function 'malloc(unsigned long)' 'std::malloc(unsigned long)' nsAllocatorManager.cp line 734 void *newBlock = ::malloc(space);

Heh, well here's the patch I used to fix this bug *last* time I hit it, with CodeWarrior 6 :) Conrad... comments? http://bugzilla.mozilla.org/showattachment.cgi?attach_id=15586

Ah crap! I just realised I was building Classic not Carbon (macperl saw a different prefs file when I'm booted into OS X vs. OS 9 - fixed that one) So all of the stuff above applies to Classic builds with CodeWarrior 7 - which of course Conrad hasn't done yet...

Carbon is going much better, but I have issues with PPBrowser - I've done all the usual stuff like deleting project Data folders for PPBrowser.mcp and Powerplant.mcp and rebuilding them. Any ideas? Link Error : undefined 'LTimerTaskFunctor::~LTimerTaskFunctor()' (descriptor) Referenced from '@2291' in PowerPlantCarbonDebug.o Link Error : undefined 'LTimerTaskFunctor::~LTimerTaskFunctor()' (code) Referenced from 'UMouseTracking::TrackMouseDownWithAction(OpaqueGrafPtr*,Point& ,unsigned short&,void (*)(void*),unsigned long,void*)' in PowerPlantCarbonDebug.o Link Error : undefined 'LTimerTask::SetUserData(void*)' (code) Referenced from 'UMouseTracking::TrackMouseDownWithAction(OpaqueGrafPtr*,Point& ,unsigned short&,void (*)(void*),unsigned long,void*)' in PowerPlantCarbonDebug.o Link Error : undefined 'LTimerTaskFunctor::LTimerTaskFunctor(OpaqueEventLoopRef*,double,double,void (* )(LTimerTask*))' (code) Referenced from 'UMouseTracking::TrackMouseDownWithAction(OpaqueGrafPtr*,Point& ,unsigned short&,void (*)(void*),unsigned long,void*)' in PowerPlantCarbonDebug.o

Add the files LTimerTask.cp and LTimerTaskFunctor.cp to lib/mac/PowerPlant/PowerPlant.mcp. They go in the "Support Classes" section.

With that change, and the stuff for the CodeWarrior SDK I mentioned it builds for me! Debug build seems to be running pretty well. Kudos Conrad.

> With that change, and the stuff for the CodeWarrior SDK I mentioned I'm still not clear why you had to change that. I used the same plugin SDK we've been using, linked the tools with CarbonLib instead of InterfaceLib, and everything was fine.

Well, the very specific problem I have is that "PluginLib4" no longer exists in the 7.0 (or 6.0) SDK - there are 2 files "PluginLib4.lib" and "PluginLib4.shlb". of these, only "PluginLib4.shlb" will work, if you try to include "PluginLib4.lib" in the Carbon build one gets an "Illegal object data" error (or words to that effect). The other comment is less direct - the notes with the 6.X/7.X CodeWarrior SDK imply one should not copy the SDk folder into the standard Access Paths, rather one should add custom Access Paths to your project so as to use the SDK from the location it is installed. I'm not sure it really matters, but it occurs to me that we could simplify our build instructions, which currently specify that the SDK must be manually installed with CodeWarrior pro5, by instead editing the xpidl.mcp project to refer to the location where the CodeWarrior SDK is installed by default with Pro7. In other woulds it would removes a step from the "setting up a build environment" instructions, and it may be more in line with what Metrowerks recommend.

> In other woulds it would removes a step from the "setting up a build > environment" instructions, and it may be more in line with what Metrowerks > recommend. I'm all for that. BTW, I used the old plugin SDK that we're using for CW5. While that worked fine, now would be the time to upgrade to a newer SDK. Does the plugin SDK come on the CW7 CD (which I don't have yet)?

Yes, its on the CD. I don't recall specifically asking for it to be installed, so I think its installed by default (though obv. someone should check). Seems to be working fine for me with the changes I suggested.

The patch is old now but here's how to use it on a clean tree: Apply the tree-wide patch Put UPDATE_PROJECTS 1 and BUILD_PROJECTS 0 in your build prefs. Run the build - this will just update all the projects to CW7 Replace projects with the ones in attachment 53252 [details] - this is for projects which required more change than updating Put UPDATE_PROJECTS 0 and BUILD_PROJECTS 1 in your build prefs Run the build - this will build it.

Mass move to 0.9.7

QA to jj

Conrad - this is busted again - someone made a new target "StubsCarbon" in NSStdLib, which your version doesn't have. This uses NSStdLibCarbon.exp rather than NSStdlib.exp, so your patch will need updating to get both files again. I'll see if I can work around this, but my experience is I can't figure this .exp stuff out for myself -> can you help please?

The reason mine didn't have StubsCarbon is that there will probably be no separate StubsCarbon target for StdLibs. The reason we have two now is they're made from two different src bases, so the symbols, and therefor the .exp files had to be different. Hopefully, the differences between Carbon & Classic will only be on symbols which are not exported. I'll know soon if you can wait. I'm going to do the final pass on this and check it in soon. As far as making .exp files, here's what I did: * I turned this on in the prefix file +#define _MSL_IMP_EXP __declspec(export) and set the linker to export using #pragma. Every symbol in the Std Libs which is *meant* to be exported is declared with this macro. * Built the lib as a shared lib. This required some other libs to be already built so it would link. * I used the MPW tool DumpPef on that shared lib and dumped the export list. That was what went into the .exp file. I trimmed of the leftmost column from what DumpPef gave me and sorted the output. Doing this, you end up with a much smaller .exp list which only exports what MSL means to export. The rest of the .exp file (things like MoreFiles), were just copied from the old file.

I'm obviously doing something wrong, because when I did the dump pef, I got a strange set of symbols - well there's pretty normal, but nothing like the files in CVS. I attached one for an exmaple. I made this by building NSStdLibCarbonDebug.shlb Do you have to pass any arguments to DumpPef? Can you think of anything you missed in your instructions.

That looks about right. It shouldn't look anything like what's in the tree now. In addition to those symbols, you have to include those from other libs that are linked into nsStdLib. Again, there may not be a separate target for Carbon when all is said and done.

Hrm, it seems every time I update I get further away from a tree that builds. conrad - can you post your NSStdLib.mcp and corresponding .exp files on this bug please? It'll be great if this is all checked in by Dec-03, but I'd like to be able to build now if possible, rather than lose a week. Cheers.

I got both Carbon & Classic building on a tree pulled two days ago. Now, as long as I can keep this tree current with the tip for a few more days, we should be good. I ran into a problem on Classic. When building Interface.mcp, somehow ContextualMenu was not set to merge with output(?). I made it so and then, on linking, CW said it encountered an unexpected EOF on the file ContextualMenu. The only workaround was replace that file in CW7 with another copy from Fizzilla Tools. I installed CW7 directly from the CD but it appears that that file is corrupted. Maybe it's my hard drive? Can somebody else try this: (1) Open up Interface.mcp with CW7 (2) Check that, after the conversion, ContextualMenu is set to merge w/output (3) Build the project and see if it links

this happens off and on. i'd thought we'd put it behind us. i never did figure out if it was a packaging problem on apple's end or what. i'll try the test later today.

This is the whole patch for nspr and will need to be checked in by somebody with access. It includes the XML project as an added file so, after applying this, that should do it for nspr.

Needs to be checked in by somebody with access. Since there are a number of new XML projects, they're in an upcoming attachment. As new files in a patch, this diff would have been huge.

CC'ing javi for help with security checkin.

wtc will have to review some of the changes in attachment 59950 [details] [diff] [review], notably: Index: nsprpub/pr/src/io/prfile.c =================================================================== RCS file: /cvsroot/mozilla/nsprpub/pr/src/io/prfile.c,v retrieving revision 3.36 diff -u -2 -r3.36 prfile.c --- prfile.c 2001/06/04 04:29:34 3.36 +++ prfile.c 2001/11/30 23:49:19 @@ -204,5 +204,5 @@ } -static PRStatus PR_CALLBACK FileInfo(PRFileDesc *fd, PRFileInfo *info) +static PRStatus PR_CALLBACK FileGetInfo(PRFileDesc *fd, PRFileInfo *info) { PRInt32 rv; @@ -215,5 +215,5 @@ } -static PRStatus PR_CALLBACK FileInfo64(PRFileDesc *fd, PRFileInfo64 *info) +static PRStatus PR_CALLBACK FileGetInfo64(PRFileDesc *fd, PRFileInfo64 *info) { #ifdef XP_MAC @@ -277,6 +277,6 @@ FileSeek, FileSeek64, - FileInfo, - FileInfo64, + FileGetInfo, + FileGetInfo64, (PRWritevFN)_PR_InvalidInt, (PRConnectFN)_PR_InvalidStatus, I welcome this change; 'FileInfo' is a struct in the Mac headers, and this has bitten me before. The other changes look good to me.

This is a ZIP of all the new XML projects for security. Each XXX.xml goes directly beside its corresponding XXX.mcp. When the new files are checked in, all the .mcp files get removed.

Here's the patch I can check in.

In the actual patch for MozillaBuildList.pm, every occurance of .mcp changes to .xml which makes it hard to see what really changed which wasn't much. For this file, I just turned .xml back to .mcp.

Troubles today. I doubt this will make it by Monday - probably Wedsnesday. Once it's reviewed, it needs testing on somebody else's machine. JJ, if you can pull a branch, let me know - I'll make one tomorrow. Also, the problem in comment #38 is still unknown.

Patrick, I need your help on something with the MRJ Plugin. See this bit from the build script: # Build MRJPlugin.jar (if Java tools exist) my($linker_path) = GetCodeWarriorRelativePath("CodeWarrior Plugins:Linkers:Java Linker"); if (-e $linker_path) { print("CodeWarrior Java tools detected, building MRJPlugin.jar.\n"); - BuildProject($project_path, "MRJPlugin.jar"); + BuildProject($plugin_path . "MRJPlugin.xml", "MRJPlugin.jar"); } With the standard install of CW7, the Java tools exist, so it will build MRJPlugin.jar. This has some problems: (1) MRJPlugin.jar is checked into the tree - so why are we trying to built it? (2) If we do build it, the MRJPlugin.jar target in MRJPlugin.xml is has problems. The output for the target has some default name (not MRJPlugin.jar) That's why I updated the .xml project - so at least the output name was right. (3) The MRJPlugin.jar target has Classic System Folder relative access paths which isn't going to work when building under OS X. This needs to be figured out but, in the meanwhile, since MRJPlugin.jar is checked into the tree, I should comment out the part in the build script that would try and build it.

javi - can you r= the security changes. Pretty harmless - just some const params which were being assigned to non-const locals. CW7 doesn't take that. wtc - can you r= the nspr part. Some symbols had to be renamed to avoid name conflicts with Mac headers. Then, I just need somebody to do an overall r= of the rest, assuming Simon does the sr=. Anybody?

I've asked wtc to get someone from the NSS to review the security changes since they're all part of the NSS tree.

On Saturday, December 1, 2001, at 11:03 AM, ccarlen@netscape.com wrote: > Patrick, I need your help on something with the MRJ Plugin. See this bit from > the build script: > > # Build MRJPlugin.jar (if Java tools exist) > my($linker_path) = GetCodeWarriorRelativePath("CodeWarrior > Plugins:Linkers:Java Linker"); > if (-e $linker_path) { > print("CodeWarrior Java tools detected, building MRJPlugin.jar.\n"); > - > BuildProject($project_path, "MRJPlugin.jar"); > + > BuildProject($plugin_path . "MRJPlugin.xml", "MRJPlugin.jar"); > } > > With the standard install of CW7, the Java tools exist, so it will build > MRJPlugin.jar. This has some problems: > (1) MRJPlugin.jar is checked into the tree - so why are we trying to built it? For obvious reasons, we should build it so that is part of tinderbox. Developers have been resistant to having Java development tools in their default CodeWarrior installation, so we checked it in to at least have the bits available. I would like to cvs remove MRJPlugin.jar and have everybody build it if possible. We should always use a stock installation of CodeWarrior as possible. > (2) If we do build it, the MRJPlugin.jar target in MRJPlugin.xml is has > problems. The output for the target has some default name (not MRJPlugin.jar) > That's why I updated the .xml project - so at least the output name was right. That's fine. (3) The MRJPlugin.jar target has Classic System Folder relative access paths which isn't going to work when building under OS X. True, however this MRJPlugin project is only built for classic Mac OS 8/9. I can fix this by using the classes.zip or classes.jar that comes with CW Pro 7.

Comment on attachment 59951 [details] [diff] [review] patch for security I reviewed this patch and made some suggested changes. Please see my comments below. Are these changes required to compile security/nss under CW7 or are they compiler warning fixes? If they are compiler warning fixes, we will onl fix them on the tip of NSS. >Index: security/nss/lib/certhigh/ocsp.c >=================================================================== >RCS file: /cvsroot/mozilla/security/nss/lib/certhigh/ocsp.c,v >retrieving revision 1.1.86.1 >diff -u -2 -r1.1.86.1 ocsp.c >--- ocsp.c 2001/08/07 18:54:57 1.1.86.1 >+++ ocsp.c 2001/11/30 23:49:48 >@@ -3709,5 +3709,5 @@ > * look for the cert on an external token. > */ >- cert = PK11_FindCertFromNickname(name, NULL); >+ cert = PK11_FindCertFromNickname((char *) name, NULL); > } > if (cert == NULL) This should be fixed by changing the function prototype of PK11_FindCertFromNickname to take const char * as the first argument. I just filed bug 113323 for this change. >Index: security/nss/lib/ckfw/object.c >=================================================================== >RCS file: /cvsroot/mozilla/security/nss/lib/ckfw/object.c,v >retrieving revision 1.4 >diff -u -2 -r1.4 object.c >--- object.c 2000/05/16 01:54:45 1.4 >+++ object.c 2001/11/30 23:49:49 >@@ -33,5 +33,5 @@ > > #ifdef DEBUG >-static const char CVS_ID[] = "@(#) $RCSfile: object.c,v $ $Revision: 1.4 $ $Date: 2000/05/16 01:54:45 $ $Name: $"; >+static const char CVS_ID[] = "@(#) $RCSfile: object.c,v $ $Revision: 1.4 $ $Date: 2000/05/16 01:54:45 $ $Name: NSS_CLIENT_TAG $"; > #endif /* DEBUG */ > >@@ -627,5 +627,5 @@ > } > >- mdItem = fwObject->mdObject->GetAttribute(fwObject->mdObject, fwObject, >+ mdItem = (NSSItem *) fwObject->mdObject->GetAttribute(fwObject->mdObject, fwObject, > fwObject->mdSession, fwObject->fwSession, fwObject->mdToken, > fwObject->fwToken, fwObject->mdInstance, fwObject->fwInstance, This should be fixed by declaring the local variable mdItem as const NSSItem *mdItem; >Index: security/nss/lib/freebl/desblapi.c All the changes to this fine are fine. I probably would not bother with the for-to-while changes; they are a matter of style.

Bob, could you merge the NSS patch (attachment 59951 [details] [diff] [review]), with my suggested changes in comment #52, into the tip of NSS? Thanks.

Comment on attachment 59950 [details] [diff] [review] patch for nspr >Index: nsprpub/pr/src/io/prfile.c The changes to this file are fine. >Index: nsprpub/pr/src/md/mac/macdll.c >Index: nsprpub/pr/src/md/mac/macio.c >Index: nsprpub/pr/src/md/mac/macthr.c >Index: nsprpub/pr/src/md/mac/mdcriticalregion.c Please ask one of the Mac NSPR developers (sfraser, gordon, beard, and sdagley) to review these Mac changes.

Comment on attachment 59950 [details] [diff] [review] patch for nspr I found that Simon Fraser already noted in comment #43 that he reviewed the Mac part of this patch. So I am marking that this patch has been reviewed. r=wtc.

> Are these changes required to compile security/nss under CW7 or are they > compiler warning fixes? They cause compiler errors. Changes would need to go onto NSS_CLIENT_TAG as well.

All of the NSS changes are already in the tip: object.c rev 1.5. by wtc for bug 94685 desblapi.c rev 1.3 by wtc for bug 94685 ocsp.c rev 1.3 by relyea NOTE: for integration into the CLIENT_BRANCH, please use rev 1.5 for object.c The others files actually have identical patches to the proposed path. bob

Thanks. Bob, can you check in the changes to the CLIENT_BRANCH?

Patch for security per Bob Relyea's suggestion. Conrad, when do you need this checked into NSS_CLIENT_TAG?

By friday if possible. Thank you.

Comment on attachment 60435 [details] [diff] [review] patch for security The patch for security has been checked into NSS_CLIENT_TAG.

comments: shouldn't the two occurances of + MenuRef menubar = static_cast<MenuRef>(clientData); be reinterpret_cast instead? static_cast can't be used to cast to/from void*. i'm surprised this compiles. other than that, r=pink.

r/sr=sfraser

Thanks. Pink, I changed the static_casts to reinterpret_casts.

Checked in amd .mcp files removed.

verified fixed.