The autotools scripts that come with googletest work just fine on Mac OS X, but they build only for a single architecture. If you want to use it with a universal binary (say 32- and 64-bit x86) you have to build it twice, and then use
lipo to stick it together. To avoid that hassle, I put together an Xcode project to generate a universal-binary version of the framework (it is pretty easy, in Xcode). I learned (and relearned) a few things along the way:
- You can preprocess the Info.plist (of course), and you can specify a file to be its prefix header (build setting: "Info.plist Preprocessor Prefix File" or "INFOPLIST_PREFIX_HEADER"). This is a relatively easy way to do string substitution into your Info.plist and I used it in gtest.framework to set up some version strings. One tricky thing is that the Info.plist seems to be generated before any other build phase. Hence, you can't have a "Run Script" phase extract the version strings and generate the prefix header and then use it later on in a different build phase. If you do want to autogenerate the Info.plist prefix header, the "Run Script" has to be part of a separate target and make that target a dependency of the target that generates the Info.plist.
- The $DERIVED_FILE_DIR is great for storing intermediate files. When you clean the project, the files you put in here are thrown out. Also, it appears that files you place in this directory are included in the "HEADER_SEARCH_PATHS". This is the destination I chose for the Info.plist prefix header.
- Make liberal use of the "Input Files" and "Output Files" of the Run Script Build Phase. They actually work as advertised. The script will not be run unless files in these locations have been touched.
- If you want to build a test executable that uses external frameworks (such as gtest.framework) without pulling everything together into a bundle, you can specify the DYLD_FRAMEWORK_PATH in the executable's environment variables and set it to the location of the framework. This should not be used for production executables code, only test code.
The trunk of the googletest project now includes the Xcode project to build the universal-binary framework.