We need to move to having projects checked into the tree in XML, like, now. We need this i) So we can land the static build projects easily ii) So we can easily move to new CodeWarrior versions (or even, gasp, support more than one version at a time). iii) So we get a camelot that has an uptime of > 40% iv) So we get revision history and blame for project files The perl module that I've attached to bug 81373 allows us to open a project XML file and mess with targets in that project, then write out the modified XML. This allows things like scripted target creation for the static build. It will also enable a camelot running as some Perl scripts on a Unix box which can add and remove files from specified targets in projects, which should be super-reliable (I'll work on the CGIs). Conrad has already proved that a build based on XML projects can work, using CW Pro 7EA on a branch. We need to know if we can do the same thing with Pro 5, and get the build script changes in place so that the script can run on XML projects.

Conrad, can you attach a diff showing the changes you made on the CW Pro 7 branch to have the build system use XML projects?

The changes to MozillaBuildList.pm (in its final form) are more trouble than they're worth. Basically, I replaced most occurances of .mcp with .xml. The only real code to change was to remove the .xml -> .mcp conversion from the plugin project. The 2nd attachment is a temporary routine I used to drive the export. I just commented out the guts of BuildIDLProject and BuildOneProjectWithOutput and had them call this. I set the buildfrom flag to start from common. Several things in runtime were not to be converted so I did that section by hand. The export to .xml will fail on projects which have bogus access path (client_debug, etc) and export_project will not return an error. What I did was to run it through the process once - most things were converted. Then ran it again. On the 2nd pass, any project for which it didn't say "xml_path exists - not exporting $project_path", needed checking. Of course, you could just create those paths but if they're not needed, they should be removed from the projects. BTW, In making the diffs between my tag & branch, I realized something sorely missing in Mac CVS Pro: being able to do "Advanced Diff", so you can specify revisions, on a folder.

How about projectbuilder support for OSX? Should this be a seperate bug? Sure would be nice if we could build with PB. Seems related to cleaning up the .mcp/CW .xml files.

The project changes required to go to PB are massive. Having XML format projects in the tree is certainly a start (PB can import these), but you'd have to seriously massage the XML before PB will build an imported project.

With various incantations of the last patch, we can 1. Export all projects in the tree to XML 2. Fix up the bad XML that Pro 5 generates, massage it to create new static lib targets, and save out the new XML 3. Have a regular build run off of XML files (creating new projects when the XML changes). The scripts are somewhat savvy about the CW version that created the XML, so put out XML that Pro 5 or Pro 6/7 can import.

XML::Parser has been updated. Current URLs: http://usemacperl.webjump.com/downloads/XML-Parser-2.30-bin-Mac.tar.gz http://www.cpan.org/authors/id/T/TJ/TJMATHER/XML-DOM-1.31.tar.gz

Simon - Looks great! I saw you put in something when exporting to close the messages window which was being put up by missing access paths and horking the export. While this is probably good, it is wallpapering over the problem. I hope you removed the useless access paths from the projects first and *then* applied the wallpaper ;-)

I can export to XML with the patch without having to fix the access paths. But the nice thing, now, is that we can script the removal of bad access paths from the XML projects.

Nag Nag: What is the current status of this Nag, Nag

This ain't gonna happen until we move to Pro 7 as our main devt environment. However, what we _could_ do is have a build process that runs through all the projects, exports them to XML using Pro 5, then builds from the XML using Pro 7. We'd have to check in 'special' XML files for NSStdLib etc.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

adding dependency to bug 98349, which is about to land any day now.

This happened, thanks to conrad.