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.
7 Comments RSS · Twitter
Yes, I like being able to edit the Info.plists as separate files. I was able to copy and paste in PB's XML editor, but undo didn't work.
I had nothing but trouble trying to move a project over to Xcode. For some reason, it just wouldn't generate the files it said it built - no errors, but no .app. I could even delete the build folder and Xcode would happily say it it built. Of course, there would be no build folder in my project folder.
I'm not completely ready to indict Xcode at this point. It turns out one of my RAM chips had gone bad and I was also having some Panther issues that required a reinstall (Upgrade install... riiiight). We'll see how Xcode, et al, work sans busted chip and install.
I updated my project to XCode, but now I can't call grace from C under X11 because the libraries linked are not linked proper.
Any way it sais
ZeroLink: unknown symbol '_GraceOpen'
I was able to move the .plist files into a sub-directory by adding INFOPLIST_PATH= directives to a hand-edited project file.
See http://developer.apple.com/documentation/ReleaseNotes/XcodeBuildSettings.html for a description of INFOPLIST_PATH.
/jay
Well, I've had nothing but trouble with xcode, and I still don't know why. With zerolink on, I get a run-time error from zerolink of the style "unknown symbol __ZTV8MyClass' (and abort). With zerolink off I get compile time errors "undefined symbols:"
Closer examination reveals this is "vtable for MyClass".
Nothing works anymore!
Info.plist files are separately editable text files for native targets. This is a good thing, because it frees you from the obnoxious and useless Project Builder XML editor. Ever try copy and paste in that thing? Hint: you can't.
Native targets also have a much, much, much faster make process, basically instantaneous even on large projects. If you can nail the yacc problem, I'd recommend you try again if you value your time.