After upgrading to Snow Leopard, I noticed that my tip for disabling the system's “Are you sure you want to open it?” messages for downloaded files no longer did the job. It took a bit of digging, but eventually I figured out that this was due to changes Apple made to the uniform type identifier (UTI) hierarchy.
Whereas in Leopard the public.item type was the base of the entire UTI hierarchy, in Snow Leopard it's the base only for the physical hierarchy (which appears to contain only filesystem-related types). As far as I can tell, there is no longer a single common ancestor for all UTI's, so com.apple.DownloadAssessment.plist must list each root type explicitly. Here's an updated version that does just that:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>LSRiskCategoryNeutral</key> <dict> <key>LSRiskCategoryContentTypes</key> <array> <string>public.item</string> <string>public.content</string> <string>public.database</string> <string>public.calendar-event</string> <string>public.message</string> <string>public.contact</string> <string>public.archive</string> <string>public.url-name</string> <string>public.executable</string> </array> </dict> </dict> </plist>
As before, put the file under Library/Preferences in your home directory. Then, log out and back in, and your Mac should be obnoxious-warning free.
Wed, 09 Dec 2009 05:33 UTC
Previously a little-used corner of my living room, this humble space is now the home of Skewsoft (no content at that link just yet).
After almost seven years of working for others, I've decided to strike out on my own and start a micro ISV. My focus is Mac and iPhone applications, and my goal is to produce high-quality software that makes people's lives simpler and more enjoyable. I'm still deciding what my first products will be. I have a couple ideas that I like, but I'm open to others; if there's a Mac or iPhone app you want but haven't been able to find, I'd love to hear about it.
I know I have a lot to learn about running my own business, but I think I'm up to the challenge, and I'm excited at the opportunity to make products that both me and my customers will love. Wish me luck!
In addition to GLU, another dependency for the iPhone app I've been working on is the Geospatial Data Abstraction Library (GDAL). Like most open-source software written in C/C++, the GDAL package uses autoconf and is built via the familiar "configure; make; make install" incantation. However, since Xcode doesn't provide much support for such packages, I had to figure out for myself how to build GDAL for iPhone OS.
It took a bit more work than I expected, but, through trial and error and some careful scrutiny of Xcode build logs, I eventually puzzled out the appropriate combination of compiler/linker flags and environment variables. And since I don't think anyone else should have to rediscover what I learned, I wrote a little shell script that automates the process.
To use the script, run it from the directory that contains your package's configure script. The one required argument is the target platform, which must be "device" or "simulator". Any arguments after the target will be passed to configure. Note that the script always passes --prefix, --host, --disable-shared, and --enable-static to configure, so you shouldn't specify any of those on the command line. (However, you can change the installation prefix with the -p option.) If configure succeeds, the script runs "make install". Finally, if all goes well, it prints a message saying where the files were installed.
For example, to compile and install GDAL for the device, I just run:
$ build_for_iphoneos device --without-pcraster --without-png ...
You can get more detailed usage info by passing the script the -h option.
By default, the script will install files in a subdirectory of $HOME/Developer/Platforms that mirrors the layout of /Developer/Platforms. For example, the installation prefix for a device build defaults to $HOME/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.1.sdk. The advantage of this is that you can make Xcode aware of the installed files for both the simulator and the device by adding the following under "All Configurations" in your project settings:
|Header Search Paths||$(HOME)/$(SDK_DIR)/include|
|Library Search Paths||$(HOME)/$(SDK_DIR)/lib|
Since the script builds your package as a static library, you'll also need to link against any other libraries it depends on, in addition to the library itself. For GDAL, I have to add "-lstdc++ -lz -lgdal" to the "Other Linker Flags" setting.
Hopefully, this will make life a little easier for anyone trying to use an autoconfed library in their iPhone app.
Update: As of Xcode 3.2, you should use SDK_DIR in the header and library search paths, instead of SDKROOT. I've modified the listings above accordingly.
Mon, 29 Sep 2008 04:19 UTC