| OpenDarwin | Other World Computing |
Here are some things you will need to know in order to build XPostFacto successfully. And I will probably forget some details, so feel free to ask if you run into trouble.
I've recently made some significant changes to the way the CodeWarrior project is set up, so pay attention to that below.
Building XPostFacto involves both a XCode project and a CodeWarrior project. The XCode project has targets for building the following items:
To set up the XCode environment properly, you need to make sure that gcc 2.95 and the 10.1 and 10.2 SDKs are installed when you install XCode. The reason is that some of the kernel extensions use the 10.1 or 10.2 SDKs, so that they will work in 10.1 and 10.2.
Other than that, I don't think there is anything special you need to do to set up the XCode environment.
The XPostFacto folder contains the CodeWarrior project, which builds the application called XPostFacto. The "Derived" folder in the CodeWarrior project is special. It is where the ProjectBuilder project copies the bootx.xcoff and the kernel extensions (as archived by hfsplusarchive).
The CodeWarrior project is checked into the repository as an XML export. So you will need to import the XML file into CodeWarrior in order to get a working project. What I do is save the resulting project file as XPostFacto.mcp, in the same folder as the XML file.
As of XPF 3, XPostFacto runs in both Mac OS 9 and Mac OS X. The Mac OS 9 version builds as a non-Carbon application (because that makes certain parts of the code easier--some things I need aren't in Carbon). The Mac OS X version builds as mach-o, for the same reason (I need to link to some frameworks that are mach-o frameworks). I'm using CodeWarrior 8.3.
The main dependency that is not included in the XPostFacto sources is MacApp. The XPostFacto application is based on MacApp. Previously, I had instructed you to download MacApp yourself and set it up somewhere. The difficulty is that I was actually using a patched version of MacApp (to permit building the OS X version of XPostFacto). What I've done know is include the patches in the CVS repository, and include a Makefile to set up the MacApp environment.
Also, if you are using CodeWarrior 8.3, you need to set your "Mac OS X Volume" source tree to point at the 10.2 SDK.
So, here is what you need to do to set up the CodeWarrior environment.
sh FixTypesAndCreators.shThis will add the correct file types and creators to the files from the CVS repository (since CVS doesn't preserve that sort of thing).
I originally picked MacApp (at a time it was still being developed by Apple), rather than PowerPlant, for reasons that seemed sensible at the time. It's a little awkward now, but rewriting for PowerPlant would be a ton of work, and I'm not really planning to do it. I suppose there is something appropriate about developing XPostFacto with a framework that Apple has abandoned :-)
It is also worth mentioning that XPostFacto requires Mac OS 9 or later. The reason is that the APIs for dealing with HFS+ volumes only became available in Mac OS 9. This is important in two respects. First, it permits XPostFacto to copy files with long filenames from the Mac OS X Install CD. Second, it permits XPostFacto to preserve unix-style permissions when it copies files (and unarchives them).
So, assuming that you have followed the steps given above for setting things up, here's the build process:
sudo xcodebuild install
You need to use sudo, because we want the kernel extensions to be owned by root. The kernel extensions will initially be "installed" under /tmp somewhere, but the "Package" target has a shell script that archives them for the CodeWarrior project to use. (The shell script in the "Package" target also resets the ownership of some files back to you, rather than root--this makes it easier to build things as yourself later, or just to delete the built files).
You can build individual kernel extensions within XCode for testing purposes. But once you want to incorporate them into XPostFacto, you will need to repeat the "sudo xcodebuild install" step (and then rebuild XPostFacto).
Here are some random quirks that you may want to know about.
I'm working on Tiger support, but not building in Tiger yet.
You will notice that a variety of headers are included in the CompatibleKernelHeaders directory. Each of the kernel extension targets is set up to use those headers (by having CompatibleKernelHeaders included in the header search paths). The reason is that these are the Mac OS X 10.0 version (or in some cases, 10.1) of these headers, and using them permits the kernel extensions to load in both Mac OS X 10.0, 10.1, and 10.2.
Another 10.0 vs. 10.1 issue worth noting is that PatchedIOSCSICDDrive only loads in 10.0, while PatchedSCSIDeviceType05 only loads in 10.1. In Mac OS X 10.2, neither of them loads, and they do not appear to be needed.
Most of the kernel extensions are taken from Darwin sources from Mac OS X public beta vintage, with a variety of bug fixes and updates required to keep them working.
The PowerStarCPU.kext represents an attempt to get sleep working on the powerbooks. It isn't working yet.
The PowerSurgeCPU.kext represents an attempt to get 604MP support working. It isn't working yet either.
The PatchedIOSSCICDDrive.kext and PatchedSCSIDeviceType05.kext work around certain problems in SCSI CD support in Mac OS X. There are still some problems with some CD-ROM devices that could probably be fixed.
PatchedNVRAM.kext fixes a problem reading and writing NVRAM on older machines.
OpenPMU.kext is based on the last open-source version of the ApplePMU driver. (Unfortunately, the current version is not open source, and the current binary included in Mac OS X panics on older systems).
PatchedNDRVSupport.kext works around a 10.2 problem with the cursor on the built-in video in the 7300 etc.
The "Shared Resources" target in CodeWarrior builds a SharedResources.rsrc file that is put in the application package where both the Mac OS 9 and Mac OS X versions can use it. The resources are built out of various .r files.
Of particular interest are the files located in XPostFacto/Resources/Views. These are all .r files that you might want to edit in a binary form (i.e. icons, views, picts). In order to facilitate this, there is a Makefile there which helps with the conversion between .r and .rsrc files. Basically, you can "make" either the .r or .rsrc file, and the Makefile will do the right thing.
For instance, you can "cd" to the directory, and then type "make XPFProgressWindow.rsrc". The Makefile will then run Rez to generate XPFProgressWindow.rsrc from the .r file. You can then edit the resource file with a resource editor (like AdLib or IcePick). However, it is still the .r file that is compiled into the application. So once you've done you're editing, you would "make" the .r file (i.e. "make XPFProgressWindow.r"). This then runs DeRez to turn XPFProgressWindow.rsrc into XPFProgressWindow.r.
If you create or edit files to put in the cvs repository, it seems best to use Unix line endings.
Those are all the notes that occur to me at the moment. I should probably write up some notes about the way the XPostFacto CodeWarrior application is structured, but I will put that in a separate document when I do it.
| OpenDarwin | Other World Computing |