在MacOSX上有两种创建应用程序包的方法，即Easy和Ugly。
简单的方法就是使用XCode。做完了
问题是有时候你做不到。
就我而言，我正在构建一个可构建其他应用程序的应用程序。我不能认为用户已安装XCode。我还使用MacPorts构建我的应用程序依赖的库。在分发它之前，我需要确保这些dylib与该应用程序捆绑在一起。
免责声明：我完全没有资格撰写这篇文章，其中的所有内容都已从Apple文档中闪闪发光，将现有的应用程序和反复试验分开。它对我有用，但很可能是错误的。如果您有任何更正，请给我发电子邮件。
您应该知道的第一件事是应用程序捆绑包只是一个目录。
让我们检查一个假设的foo.app的结构。
foo.app/
内容/
信息清单
苹果系统/
富
资源/
foo.icns
Info.plist是一个纯XML文件。您可以使用文本编辑器或XCode附带的属性列表编辑器应用程序对其进行编辑。（位于/ Developer / Applications / Utilities /目录中）。
您需要包括的关键内容是：
CFBundleName-应用程序的名称。
CFBundleIcon-图标文件，假定位于目录/资源目录中。使用Icon Composer应用程序创建图标。（它也位于/ Developer / Applications / Utilities /目录中），您只需将png拖放到其窗口中，即可自动为您生成mip级别。
CFBundleExecutable-假定位于Contents / MacOS /子文件夹中的可执行文件的名称。
还有更多选择，上面列出的只是最低限度的选择。这是有关Info.plist
文件和
App bundle结构的一些Apple文档
。
另外，这是示例Info.plist。
<？xml版本=“ 1.0”编码=“ UTF-8”？>
<！DOCTYPE plist PUBLIC“-// Apple Computer // DTD PLIST 1.0 // EN”“ http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version =“ 1.0”>
<dict>
<key> CFBundleGetInfoString </ key>
<string> Foo </ string>
<key> CFBundleExecutable </ key>
<string> foo </ string>
<key> CFBundleIdentifier </ key>
<string> com.your-company-name.www </ string>
<key> CFBundleName </ key>
<string> foo </ string>
<key> CFBundleIconFile </ key>
<string> foo.icns </ string>
<key> CFBundleShortVersionString </ key>
<string> 0.01 </ string>
<key> CFBundleInfoDictionaryVersion </ key>
<string> 6.0 </ string>
<key> CFBundlePackageType </ key>
<string> APPL </ string>
<key> IFMajorVersion </ key>
<integer> 0 </ integer>
<key> IFMinorVersion </ key>
<integer> 1 </ integer>
</ dict>
</ plist>
在理想情况下，您只需将可执行文件拖放到Contents / MacOS /目录中即可。但是，如果您的应用程序具有任何非标准的dylib依赖关系，它将无法正常工作。像Windows一样，MacOS也带有它自己的特殊类型的DLL Hell。
如果您使用MacPorts构建要链接的库，则dylib的位置将被硬编码到可执行文件中。如果您在具有完全相同的dylib的计算机上运行该应用程序，它将运行良好。但是，大多数用户不会安装它们。当他们双击您的应用程序时，它将崩溃。
在分发可执行文件之前，您需要收集其加载的所有Dylib，并将其复制到应用程序捆绑包中。您还需要编辑可执行文件，以便它将在正确的位置查找dylib。即您将它们复制到的位置。
手工编辑可执行文件听起来很危险，对吗？幸运的是，有命令行工具可以提供帮助。
otool -L可执行文件名
此命令将列出您的应用程序依赖的所有dylib。如果您看到不在System / Library或usr / lib文件夹中的任何文件，则需要将其复制到应用程序捆绑包中。将它们复制到/ Contents / MacOS /文件夹中。接下来，您需要编辑可执行文件以使用新的dylib。
首先，您需要确保使用-headerpad_max_install_names标志进行链接。这只是确保如果新的dylib路径长于前一个，则将有空间。
其次，使用install_name_tool更改每个dylib路径。
install_name_tool-更改existing_path_to_dylib @ executable_path / blah.dylib可执行文件名
举一个实际的例子，假设您的应用使用libSDL，而otool将其位置列为“ /opt/local/lib/libSDL-1.2.0.dylib”。
首先将其复制到应用程序捆绑包中。
cp /opt/local/lib/libSDL-1.2.0.dylib foo.app/Contents/MacOS/
然后编辑可执行文件以使用新位置（注意：确保使用-headerpad_max_install_names标志构建了该可执行文件）
install_name_tool -change /opt/local/lib/libSDL-1.2.0.dylib @ executable_path / libSDL-1.2.0.dylib foo.app/Contents/MacOS/foo
ew，我们快完成了。现在，当前工作目录存在一个小问题。
启动应用程序时，当前目录将是该应用程序所在目录的上方。例如：如果将foo.app放在/ Applcations文件夹中，则启动应用程序时的当前目录将是/ Applications文件夹。并非您所期望的/Applications/foo.app/Contents/MacOS/。
您可以更改您的应用程序以解决此问题，也可以使用这个神奇的小启动器脚本来更改当前目录并启动您的应用程序。
＃！/ bin / bash
cd“ $ {0％/ *}”
./foo
确保调整Info.plist文件，以使CFBundleExecutable指向启动脚本，而不指向先前的可执行文件。
好的，现在全部完成。幸运的是，一旦您知道所有这些东西，便将其埋入构建脚本中。