Mac OS X 10.3 Developer Tools
All things considered, I wish I hadn’t updated my development machine to Mac OS X 10.3. I’m generally very pleased with Panther, but the developer tools have so far done nothing but waste my time.
I tried to edit a nib in Interface Builder, to add a few columns to a table. That was easy enough, but when I built and ran the application the new columns didn’t show. I opened the nib in IB again, and it showed the columns just fine. I don’t know what went wrong, since I didn’t change the nib format or use any new 10.3 attributes. I checked out a fresh copy of the nib from CVS and made the change again. Still no dice. After a few more tries, it eventually worked. I’m not sure why.
I loaded some of my Project Builder projects into Xcode. The files are packages whose names end with .pbproj, so of course the system still thinks they belong to Project Builder. I used the Finder to override the files so they would open in Xcode. To do this, it saved two invisible files inside each project: .LSOverride and Icon\r. (The \r is ASCII 13.) BBEdit didn’t like this; it kept giving me error -43 (file not found) when I tried to Find Lurkers in my sandbox. Eventually I figured out that it didn’t like the Icon\r files. I couldn’t figure out how to add the literal text Icon\r to my .cvsignore file, so I ended up settling for Icon?. (The question mark is a wildcard that matches a single character.)
Xcode has been giving me a lot of trouble in addition to the issues I previously mentioned. I let Xcode update my targets to its native format, deleted the classic targets, and fixed up all the names. It insisted on creating new Info.plist files for all my non-tool targets and placing them next to the project file.
I try to keep the project folder tidy, so I moved the files into another folder. Xcode lost track of them. I updated the paths in the project window so that it could find them, only it didn’t really find them. The corresponding text fields in the Properties tab of the Target settings were blank, and even when I re-entered the information Xcode refused to use it, or even save it when I closed the project. Eventually I figured out that I had to update the relative path in the INFOPLIST_FILE setting in the Build tab of the Target settings.
Xcode still wouldn’t compile the code, though. It seems there’s a bug in the shell script that Xcode generates when compiling yacc files. It gets some of the relative paths wrong. I didn’t know how to customize Xcode’s handling of derived source files, so I decided to go back to the classic target.
The yacc files worked fine with the classic target, but Xcode gave me some errors about the availability macros. (These let me develop on the latest version of Mac OS X and make sure I’m not using any new APIs that will prevent my code from running on older versions of the OS.) Often, these sorts of errors in Project Builder and Xcode go away if I do a clean build. This time some of them did, but not all.
No problem, I thought, I’ll use Xcode’s new cross-development feature, which lets me develop using the 10.2.7 headers while running on 10.3. Unfortunately, although I could select that option in my project, Xcode ignored it for classic targets. So I was back to using the availability macros with the 10.3 SDK. I decided that I could do without MAC_OS_X_VERSION_MIN_REQUIRED, which was causing the errors, and just use MAC_OS_X_VERSION_MAX_ALLOWED. This stopped the errors, but then Xcode started complaining about some glyph and animation stuff in AppKit. It turns out that NSGraphics.h and NSLayoutManager.h have bugs; some new symbols aren’t protected by the availability macros. I authenticated and fixed the header files.
Now everything builds in Xcode using classic targets, which means that I can’t take advantage of new features like distributed builds. I could probably update a dozen or so of the targets to native, but I’d rather get back to coding.
