Hay dos formas de crear un paquete de aplicaciones en MacOSX, Easy y Ugly.
La forma más sencilla es utilizar XCode. Hecho.
El problema es que a veces no puedes.
En mi caso, estoy creando una aplicación que crea otras aplicaciones. No puedo asumir que el usuario tiene XCode instalado. También estoy usando MacPorts para crear las bibliotecas de las que depende mi aplicación. Necesito asegurarme de que estos dylibs se incluyan con la aplicación antes de distribuirla.
Descargo de responsabilidad: no estoy calificado para escribir esta publicación, todo lo que contiene ha sido extraído de los documentos de Apple, seleccionando aplicaciones existentes y prueba y error. Funciona para mí, pero probablemente sea incorrecto. Por favor envíeme un correo electrónico si tiene alguna corrección.
Lo primero que debe saber es que un paquete de aplicaciones es solo un directorio.
Examinemos la estructura de un foo.app hipotético.
foo.app/
Contenido/
Info.plist
Mac OS/
foo
Recursos /
foo.icns
Info.plist es un archivo XML simple. Puede editarlo con un editor de texto o la aplicación Property List Editor que viene con XCode. (Está en el directorio / Developer / Applications / Utilities /).
Las cosas clave que debe incluir son:
CFBundleName : el nombre de la aplicación.
CFBundleIcon : un archivo de icono que se supone que está en el directorio de contenidos / recursos. Utilice la aplicación Icon Composer para crear el icono. (También está en el directorio / Developer / Applications / Utilities /). Puede simplemente arrastrar y soltar un png en su ventana y debería generar automáticamente los niveles de mip para usted.
CFBundleExecutable : nombre del archivo ejecutable que se supone que está en la subcarpeta Contenidos / MacOS /.
Hay muchas más opciones, las enumeradas anteriormente son solo las mínimas. Aquí hay algo de documentación de Apple sobre el
archivo Info.plist y la
estructura del paquete de aplicaciones .
Además, aquí hay una muestra de 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">
<dicto>
<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>
En un mundo perfecto, simplemente podría colocar su ejecutable en el directorio Contenidos / MacOS / y listo. Sin embargo, si su aplicación tiene dependencias dylib no estándar, no funcionará. Al igual que Windows, MacOS viene con su propio tipo especial de DLL Hell .
Si está utilizando MacPorts para crear bibliotecas con las que se vincula, las ubicaciones de los dylibs estarán codificadas en su ejecutable. Si ejecuta la aplicación en una máquina que tiene los dylibs en la misma ubicación exacta, funcionará bien. Sin embargo, la mayoría de los usuarios no los instalarán; cuando hagan doble clic en su aplicación, simplemente se bloqueará.
Antes de distribuir su ejecutable, deberá recopilar todos los archivos dylib que carga y copiarlos en el paquete de aplicaciones. También necesitará editar el ejecutable para que busque los dylibs en el lugar correcto. es decir, dónde los copió.
La edición manual de un ejecutable suena peligroso, ¿verdad? Afortunadamente, existen herramientas de línea de comandos para ayudar.
otool -L nombre_ejecutable
Este comando enumerará todos los dylibs de los que depende su aplicación. Si ve alguno que NO esté en la carpeta System / Library o usr / lib, esos son los que deberá copiar en el paquete de la aplicación. Cópielos en la carpeta / Contenido / MacOS /. A continuación, deberá editar el ejecutable para usar los nuevos dylibs.
Primero, debes asegurarte de vincular usando la marca -headerpad_max_install_names. Esto solo asegura que si la nueva ruta dylib es más larga que la anterior, habrá espacio para ella.
En segundo lugar, use install_name_tool para cambiar cada ruta de dylib.
install_name_tool -cambiar ruta_existente_a_dylib @ ruta_ejecutable / blah.dylib nombre_ejecutable
Como ejemplo práctico, digamos que su aplicación usa libSDL y otool enumera su ubicación como "/opt/local/lib/libSDL-1.2.0.dylib".
Primero cópielo en el paquete de la aplicación.
cp /opt/local/lib/libSDL-1.2.0.dylib foo.app/Contents/MacOS/
Luego edite el ejecutable para usar la nueva ubicación (NOTA: asegúrese de haberlo construido con el indicador -headerpad_max_install_names)
install_name_tool -change /opt/local/lib/libSDL-1.2.0.dylib @ ruta_ejecutable / libSDL-1.2.0.dylib foo.app/Contents/MacOS/foo
Vaya, casi hemos terminado. Ahora hay un pequeño problema con el directorio de trabajo actual.
Cuando inicie su aplicación, el directorio actual será el directorio arriba donde se encuentra la aplicación. Por ejemplo: si coloca foo.app en la carpeta / Applcations, el directorio actual cuando inicie la aplicación será la carpeta / Aplicaciones. No el /Applications/foo.app/Contents/MacOS/ como cabría esperar.
Puede modificar su aplicación para que tenga en cuenta esto, o puede usar este pequeño script de iniciador mágico que cambiará el directorio actual e iniciará su aplicación.
#! / bin / bash
cd "$ {0% / *}"
./foo
Asegúrese de ajustar el archivo Info.plist para que CFBundleExecutable apunte al script de inicio y no al ejecutable anterior.
Ok, todo hecho ahora. Afortunadamente, una vez que conoces todo esto, lo entierras en un script de compilación.