Closed Bug 88340 Opened 19 years ago Closed 18 years ago

Mac build should use XML-format project files

Categories

(SeaMonkey :: Build Config, defect, P2)

PowerPC
Mac System 8.5
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.0.1

People

(Reporter: sfraser_bugs, Assigned: sfraser_bugs)

References

Details

Attachments

(3 files)

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?
Status: NEW → ASSIGNED
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.
Priority: -- → P2
Target Milestone: --- → mozilla1.0
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.
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
adding dependency to bug 98349, which is about to land any day now.
Depends on: 98349
This happened, thanks to conrad.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.