Есть два способа создать пакет приложений в MacOSX: Простой и Уродливый.
Самый простой способ - просто использовать XCode. Выполнено.
Проблема в том, что иногда вы не можете.
В моем случае я создаю приложение, которое собирает другие приложения. Я не могу предположить, что у пользователя установлен XCode. Я также использую MacPorts для создания библиотек, от которых зависит мое приложение. Мне нужно убедиться, что эти дилибы включены в приложение, прежде чем я его распространю.
Отказ от ответственности: я совершенно не квалифицирован, чтобы писать этот пост, все в нем было отражено в документации Apple, отбирая существующие приложения и методом проб и ошибок. У меня работает, но скорее всего не так. Пожалуйста, напишите мне, если у вас есть исправления.
Первое, что вам следует знать, это то, что набор приложений - это просто каталог.
Давайте рассмотрим структуру гипотетического foo.app.
foo.app/
Содержание /
Info.plist
MacOS /
фу
Ресурсы/
foo.icns
Info.plist - это простой файл XML. Вы можете редактировать его с помощью текстового редактора или приложения Property List Editor, которое поставляется вместе с XCode. (Он находится в каталоге / Developer / Applications / Utilities /).
Ключевые вещи, которые вам нужно включить:
CFBundleName - название приложения.
CFBundleIcon - файл значка, который предположительно находится в каталоге Contents / Resources. Используйте приложение Icon Composer для создания значка. (Он также находится в каталоге / Developer / Applications / Utilities /). Вы можете просто перетащить png в его окно и автоматически сгенерировать для вас уровни mip.
CFBundleExecutable - имя исполняемого файла, который должен находиться в подпапке Contents / MacOS /.
Есть еще много вариантов, перечисленные выше - это лишь минимум. Вот некоторая документация Apple по
файлу Info.plist и
структуре пакетов приложений .
Кроме того, вот образец Info.plist.
<? xml version = "1.0" encoding = "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> Фу </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> ПРИЛОЖЕНИЕ </string>
<key> IFMajorVersion </key>
<integer> 0 </integer>
<key> IFMinorVersion </key>
<integer> 1 </integer>
</dict>
</plist>
В идеальном мире вы можете просто поместить свой исполняемый файл в папку Contents / MacOS / и все готово. Однако, если ваше приложение имеет нестандартные зависимости dylib, оно не будет работать. Как и Windows, MacOS имеет свой особый вид DLL Hell .
Если вы используете MacPorts для создания библиотек, которые вы связываете, расположение dylibs будет жестко закодировано в вашем исполняемом файле. Если вы запустите приложение на компьютере, на котором файлы dylib находятся в одном и том же месте, оно будет работать нормально. Однако у большинства пользователей они не установлены; когда они дважды щелкают по вашему приложению, оно просто вылетает.
Перед распространением исполняемого файла вам необходимо собрать все загружаемые им дилибы и скопировать их в пакет приложений. Вам также потребуется отредактировать исполняемый файл, чтобы он искал дилибы в нужном месте. т.е. куда вы их скопировали.
Редактирование исполняемого файла вручную кажется опасным, не так ли? К счастью, в этом могут помочь инструменты командной строки.
otool -L имя_исполняемого_файла
Эта команда выведет список всех дилибов, от которых зависит ваше приложение. Если вы видите что-то, чего НЕТ в папке System / Library или usr / lib, это те, которые вам нужно скопировать в пакет приложений. Скопируйте их в папку / Contents / MacOS /. Затем вам нужно отредактировать исполняемый файл, чтобы использовать новые файлы dylib.
Во-первых, вам нужно убедиться, что вы устанавливаете ссылку с помощью флага -headerpad_max_install_names. Это просто гарантирует, что если новый путь dylib длиннее предыдущего, для него останется место.
Во-вторых, используйте install_name_tool для изменения каждого пути к dylib.
install_name_tool -change 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
Уф, мы почти закончили. Теперь есть небольшая проблема с текущим рабочим каталогом.
Когда вы запускаете приложение, текущим каталогом будет каталог, расположенный выше, в котором расположено приложение. Например: если вы поместите файл foo.app в папку / Applcations, тогда текущим каталогом при запуске приложения будет папка / Applications. Не /Applications/foo.app/Contents/MacOS/, как вы могли ожидать.
Вы можете изменить свое приложение, чтобы учесть это, или вы можете использовать этот волшебный маленький скрипт запуска, который изменит текущий каталог и запустит ваше приложение.
#! / bin / bash
cd "$ {0% / *}"
./foo
Убедитесь, что вы настроили файл Info.plist так, чтобы CFBundleExecutable указывал на сценарий запуска, а не на предыдущий исполняемый файл.
Хорошо, теперь все готово. К счастью, когда вы знаете все это, вы закапываете это в скрипт сборки.