Carthage
0.40.0
Carthage pretende ser la forma más sencilla de agregar marcos a su aplicación Cocoa.
Carthage construye tus dependencias y te proporciona marcos binarios, pero tú conservas el control total sobre la estructura y configuración de tu proyecto. Carthage no modifica automáticamente los archivos de su proyecto ni la configuración de su compilación.
Obtenga Carthage ejecutando brew install carthage o elija otro método de instalación
Cree un Cartfile en el mismo directorio donde está su .xcodeproj o .xcworkspace
Enumere las dependencias deseadas en Cartfile, por ejemplo:
github "Alamofire/Alamofire" ~> 5.5
Ejecute carthage update --use-xcframeworks
Un archivo Cartfile.resolved y un directorio Carthage aparecerán en el mismo directorio donde está su .xcodeproj o .xcworkspace
Arrastre los paquetes .xcframework creados desde Carthage/Build a la sección "Marcos y bibliotecas" del proyecto Xcode de su aplicación.
Si está utilizando Carthage para una aplicación, seleccione "Incrustar y firmar"; de lo contrario, "No incrustar".
Para obtener una guía detallada, siga leyendo en Agregar marcos a una aplicación.
Hay múltiples opciones para instalar Carthage:
Instalador: descargue y ejecute el archivo Carthage.pkg para obtener la última versión, luego siga las instrucciones en pantalla. Si está instalando el paquete a través de CLI, es posible que primero necesite ejecutar sudo chown -R $(whoami) /usr/local .
Homebrew: Puede usar Homebrew e instalar la herramienta carthage en su sistema simplemente ejecutando brew update y brew install carthage . (nota: si instaló previamente la versión binaria de Carthage, debe eliminar /Library/Frameworks/CarthageKit.framework ).
MacPorts: puede usar MacPorts e instalar la herramienta carthage en su sistema simplemente ejecutando sudo port selfupdate y sudo port install carthage . (nota: si instaló previamente la versión binaria de Carthage, debe eliminar /Library/Frameworks/CarthageKit.framework ).
Desde la fuente: si desea ejecutar la última versión de desarrollo (que puede ser muy inestable o incompatible), simplemente clone la rama master del repositorio y luego ejecute make install . Requiere Xcode 10.0 (Swift 4.2).
Una vez que haya instalado Carthage, puede comenzar a agregar marcos a su proyecto. Tenga en cuenta que Carthage solo admite marcos dinámicos, que solo están disponibles en iOS 8 o posterior (o cualquier versión de OS X).
carthage update --use-xcframeworks . Esto buscará dependencias en una carpeta Carthage/Checkouts y compilará cada una o descargará un XCFramework precompilado.Recomendamos el uso de XCFrameworks a partir de la versión 0.37.0 (enero de 2021) y exigimos XCFrameworks al compilar en una Apple Silicon Mac. Cambiar de paquetes de marcos discretos a XCFrameworks requiere algunos cambios en su proyecto:
Carthage/Build para eliminar cualquier paquete de marco existente.carthage build --use-xcframeworks . Cualquier otro argumento que construya se puede proporcionar como de costumbre.carthage copy-frameworks del objetivo, si está presente.Incompatibilidad con Xcode 12+ : las plataformas de múltiples arquitecturas no son compatibles cuando se crean paquetes de marcos en Xcode 12 y versiones posteriores. Prefiere compilar con XCFrameworks. Si necesita crear paquetes de marcos discretos, utilice un archivo xcconfig de solución alternativa.
carthage update --platform macOS . Esto buscará dependencias en una carpeta Carthage/Checkouts y compilará cada una o descargará un marco precompilado.Además, deberá copiar los símbolos de depuración para la depuración y los informes de fallos en OS X.
Cree un Cartfile que enumere los marcos que le gustaría usar en su proyecto.
Ejecute carthage update . Esto buscará las dependencias en una carpeta Carthage/Checkouts, luego compilará cada una o descargará un marco precompilado.
Abra la pestaña de configuración general de los objetivos de su aplicación. Para Xcode 11.0 y superior, en la sección "Marcos, bibliotecas y contenido incrustado", arrastre y suelte cada marco que desee usar desde la carpeta Carthage/Build en el disco. Luego, en la sección "Incrustar", seleccione "No incrustar" en el menú desplegable para cada elemento agregado. Para Xcode 10.x y versiones anteriores, en la sección "Bibliotecas y marcos vinculados", arrastre y suelte cada marco que desee usar desde la carpeta Carthage/Build en el disco.
En la pestaña de configuración de Fases de compilación de los objetivos de su aplicación, haga clic en el ícono + y elija Nueva fase de ejecución de script . Cree un script de ejecución en el que especifique su shell (por ejemplo, /bin/sh ), agregue el siguiente contenido al área del script debajo del shell:
/usr/local/bin/carthage copy-frameworks Cree un archivo llamado input.xcfilelist y un archivo llamado output.xcfilelist
Agregue las rutas a los marcos que desea usar a su input.xcfilelist . Por ejemplo:
$(SRCROOT)/Carthage/Build/iOS/Result.framework
$(SRCROOT)/Carthage/Build/iOS/ReactiveSwift.framework
$(SRCROOT)/Carthage/Build/iOS/ReactiveCocoa.framework
Agregue las rutas a los marcos copiados a output.xcfilelist . Por ejemplo:
$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/Result.framework
$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/ReactiveSwift.framework
$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/ReactiveCocoa.framework
Con los archivos de salida especificados junto con los archivos de entrada, Xcode solo necesita ejecutar el script cuando los archivos de entrada han cambiado o faltan los archivos de salida. Esto significa que las compilaciones sucias serán más rápidas cuando no hayas reconstruido los marcos con Carthage.
Agregue input.xcfilelist a la sección "Listas de archivos de entrada" de la fase de ejecución del script de Carthage
Agregue el output.xcfilelist a la sección "Listas de archivos de salida" de la fase de ejecución del script de Carthage.
Este script soluciona un error de envío de la App Store provocado por binarios universales y garantiza que los archivos necesarios relacionados con códigos de bits y dSYM se copien al archivar.
Con la información de depuración copiada en el directorio de productos creados, Xcode podrá simbolizar el seguimiento de la pila cada vez que se detenga en un punto de interrupción. Esto también le permitirá recorrer el código de terceros en el depurador.
Al archivar su aplicación para enviarla a App Store o TestFlight, Xcode también copiará estos archivos en el subdirectorio dSYMs del paquete .xcarchive de su aplicación.
En el camino, Cartago habrá creado algunos artefactos de construcción. El más importante de ellos es el archivo Cartfile.resolved, que enumera las versiones que realmente se crearon para cada marco. Asegúrese de confirmar su Cartfile.resolved , porque cualquier otra persona que use el proyecto necesitará ese archivo para crear las mismas versiones del marco.
Puede agregar una fase Ejecutar script para advertirle automáticamente cuando una de sus dependencias esté desactualizada.
Build Phases de los objetivos de su aplicación, haga clic en el ícono + y elija New Run Script Phase . Cree un script de ejecución en el que especifique su shell (por ejemplo, /bin/sh ), agregue el siguiente contenido al área del script debajo del shell: /usr/local/bin/carthage outdated --xcode-warnings 2> /dev/nullCarthage comprobará para asegurarse de que los marcos Swift descargados (y una combinación de Objective-C/Swift) se hayan creado con la misma versión de Swift que se utiliza localmente. Si hay una discrepancia en la versión, Carthage procederá a construir el marco desde la fuente. Si el marco no se puede construir desde la fuente, Carthage fracasará.
Debido a que Carthage usa la salida de xcrun swift --version para determinar la versión local de Swift, asegúrese de ejecutar los comandos de Carthage con la cadena de herramientas Swift que desea utilizar. Para muchos casos de uso, no se necesita nada adicional. Sin embargo, por ejemplo, si está creando un proyecto Swift 2.3 usando Xcode 8.x, una forma de especificar su swift predeterminado para carthage bootstrap es usar el siguiente comando:
TOOLCHAINS=com.apple.dt.toolchain.Swift_2_3 carthage bootstrap
Una vez que haya finalizado los pasos anteriores y haya realizado sus cambios, otros usuarios del proyecto solo necesitan buscar el repositorio y ejecutar carthage bootstrap para comenzar con los marcos que agregó.
Usar Carthage para las dependencias de cualquier objetivo arbitrario es bastante similar a usar Carthage para una aplicación. La principal diferencia radica en cómo se configuran y vinculan los marcos en Xcode.
Debido a que a los objetivos de prueba unitaria les falta la sección Bibliotecas y marcos vinculados en su pestaña Configuración general , debe arrastrar los marcos creados a la fase de compilación Vincular binarios con bibliotecas .
En el objetivo de prueba en la pestaña Configuración de compilación , agregue @loader_path/Frameworks a las rutas de búsqueda de Runpath si aún no está presente.
En casos excepcionales, es posible que desee copiar también cada dependencia en el producto de compilación (por ejemplo, para incrustar dependencias dentro del marco externo o asegurarse de que las dependencias estén presentes en un paquete de prueba). Para hacer esto, cree una nueva fase de compilación de Copiar archivos con el destino de Frameworks y luego agregue allí también la referencia del framework. No debe usar el comando carthage copy-frameworks ya que los paquetes de prueba no necesitan marcos eliminados y no se admite la ejecución simultánea de instancias de copy-frameworks (con compilaciones paralelas activadas).
Si modificó su Cartfile o desea actualizar a las versiones más recientes de cada marco (sujeto a los requisitos que haya especificado), simplemente ejecute el comando carthage update nuevamente.
Si solo desea actualizar una dependencia o dependencias específicas, páselas como una lista separada por espacios al comando update . p.ej
carthage update Box
o
carthage update Box Result
Se realizó una reescritura de la lógica para actualizar los marcos con el objetivo de aumentar la velocidad y reducir el uso de memoria. Actualmente es una función de suscripción voluntaria. Se puede utilizar pasando --new-resolver al comando de actualización, por ejemplo,
carthage update --new-resolver Box
Si tiene problemas de rendimiento durante las actualizaciones, pruebe el nuevo solucionador
Si el marco que desea agregar a su proyecto tiene dependencias enumeradas explícitamente en un Cartfile, Carthage las recuperará automáticamente. Luego tendrás que arrastrarlos tú mismo a tu proyecto desde la carpeta Carthage/Build.
Si el marco integrado en su proyecto tiene dependencias con otros marcos, debe vincularlos al objetivo de la aplicación (incluso si el objetivo de la aplicación no depende de esos marcos y nunca los usa).
De forma predeterminada, Carthage verificará directamente los archivos fuente de las dependencias en la carpeta de su proyecto, permitiéndole confirmarlos o ignorarlos según lo desee. Si en su lugar desea tener dependencias disponibles como submódulos de Git (tal vez para poder confirmar y enviar cambios dentro de ellos), puede ejecutar carthage update o carthage checkout con el indicador --use-submodules .
Cuando se ejecuta de esta manera, Carthage escribirá en los archivos .gitmodules y .git/config de su repositorio, y actualizará automáticamente los submódulos cuando cambien las versiones de las dependencias.
Si desea trabajar en sus dependencias durante el desarrollo y desea que se reconstruyan automáticamente cuando cree su proyecto principal, puede agregar una fase de compilación Ejecutar script que invoque a Carthage de esta manera:
/usr/local/bin/carthage build --platform " $PLATFORM_NAME " --project-directory " $SRCROOT "Tenga en cuenta que debería utilizar submódulos antes de hacer esto, porque las cajas simples no deben modificarse directamente.
De forma predeterminada, Carthage reconstruirá una dependencia independientemente de si es la misma versión resuelta que antes. Pasar --cache-builds hará que cartago evite reconstruir una dependencia si puede. Consulte la información sobre los archivos de versión para obtener detalles sobre cómo Carthage realiza este almacenamiento en caché.
Nota: En este momento --cache-builds es incompatible con --use-submodules . El uso de ambos dará como resultado que la copia de trabajo y los cambios confirmados en la dependencia de su submódulo no se reconstruyan correctamente. Consulte el n.° 1785 para obtener más detalles.
La finalización automática de los comandos y opciones de Carthage está disponible como se documenta en Bash/Zsh/Fish Completion.
Carthage solo admite oficialmente marcos dinámicos . Los marcos dinámicos se pueden utilizar en cualquier versión de OS X, pero sólo en iOS 8 o posterior . Además, desde la versión 0.30.0, Carthage admite marcos estáticos .
Debido a que Carthage no tiene una lista de paquetes centralizada ni un formato de especificación de proyecto, la mayoría de los marcos deberían compilarse automáticamente .
Los requisitos específicos de cualquier proyecto marco se enumeran a continuación.
Carthage solo creará esquemas Xcode que se compartan desde su .xcodeproj . Puede ver si todos los esquemas previstos se compilan correctamente ejecutando carthage build --no-skip-current y luego revisando la carpeta Carthage/Build.
Si no se crea un esquema importante cuando ejecuta ese comando, abra Xcode y asegúrese de que el esquema esté marcado como Compartido , para que Carthage pueda descubrirlo.
Si encuentra fallas de compilación en carthage build --no-skip-current , intente ejecutar xcodebuild -scheme SCHEME -workspace WORKSPACE build o xcodebuild -scheme SCHEME -project PROJECT build (con los valores reales) y vea si ocurre la misma falla allí. Es de esperar que esto proporcione suficiente información para resolver el problema.
Si tiene instaladas varias versiones de las herramientas de desarrollo de Apple (una versión beta de Xcode, por ejemplo), use xcode-select para cambiar la versión que usa Carthage.
Si aún no puede crear su marco con Carthage, abra un problema y estaremos encantados de ayudarle.
Carthage determina qué versiones de su marco están disponibles buscando entre las etiquetas publicadas en el repositorio e intentando interpretar cada nombre de etiqueta como una versión semántica. Por ejemplo, en la etiqueta v1.2 , la versión semántica es 1.2.0.
Las etiquetas sin ningún número de versión o con algún carácter después del número de versión (por ejemplo, 1.2-alpha-1 ) actualmente no son compatibles y serán ignoradas.
Carthage puede usar automáticamente marcos prediseñados, en lugar de compilarlos desde cero, si están adjuntos a una versión de GitHub en el repositorio de su proyecto o mediante un archivo binario de definición de proyecto.
Para ofrecer marcos prediseñados para una etiqueta específica, los archivos binarios de todas las plataformas compatibles se deben comprimir en un solo archivo, y ese archivo se debe adjuntar a una versión publicada correspondiente a esa etiqueta. El archivo adjunto debe incluir .framework en su nombre (por ejemplo, ReactiveCocoa.framework.zip ), para indicarle a Carthage que contiene archivos binarios. La estructura de directorios del archivo es libre, pero los marcos solo deben aparecer una vez en el archivo , ya que se copiarán en Carthage/Build/<platform> según su nombre (por ejemplo, ReactiveCocoa.framework ).
Para ofrecer XCFrameworks prediseñado, compílelo con --use-xcframeworks y siga el mismo proceso para comprimir todos los XCFrameworks en un solo archivo. Incluya .xcframework en el nombre del archivo adjunto. A partir de la versión 0.38.0, Carthage prefiere descargar archivos adjuntos .xcframework cuando se pasa --use-xcframeworks .
Puede realizar la operación de archivado con Cartago usando:
-carthage build --no-skip-current
-carthage archive YourFrameworkNameo alternativamente
carthage build --archiveLos borradores de versiones se ignorarán automáticamente, incluso si corresponden a la etiqueta deseada.
Es posible utilizar travis-ci para crear y cargar sus lanzamientos etiquetados.
Instale la CLI de travis con gem install travis
Configure travis-ci para su repositorio (Pasos 1 y 2)
Cree el archivo .travis.yml en la raíz de su repositorio según esa plantilla. Establezca FRAMEWORK_NAME en el valor correcto.
Reemplace PROJECT_PLACEHOLDER y SCHEME_PLACEHOLDER
Si está utilizando un espacio de trabajo en lugar de un proyecto, elimine la línea xcode_project y descomente la línea xcode_workspace.
El proyecto debe tener el formato: MyProject.xcodeproj
El espacio de trabajo debe tener el formato: MyWorkspace.xcworkspace
No dude en actualizar el valor de xcode_sdk a otro SDK. Tenga en cuenta que para realizar pruebas en el SDK de iphoneos sería necesario cargar una identidad de firma de código.
Para obtener más información, puede visitar Travis Docs para proyectos Objective-C.
language : objective-c
osx_image : xcode7.3
xcode_project : <PROJECT_PLACEHOLDER>
# xcode_workspace: <WORKSPACE_PLACEHOLDER>
xcode_scheme : <SCHEME_PLACEHOLDER>
xcode_sdk : iphonesimulator9.3
env :
global :
- FRAMEWORK_NAME=<THIS_IS_A_PLACEHOLDER_REPLACE_ME>
before_install :
- brew update
- brew outdated carthage || brew upgrade carthage
before_script :
# bootstrap the dependencies for the project
# you can remove if you don't have dependencies
- carthage bootstrap
before_deploy :
- carthage build --no-skip-current
- carthage archive $FRAMEWORK_NAME Ejecute travis setup releases , siga la documentación aquí
Este comando codificará sus credenciales de GitHub en el archivo .travis.yml para permitir que Travis cargue la versión en GitHub.com. Cuando se le solicite cargar el archivo, ingrese $FRAMEWORK_NAME.framework.zip
Actualice la sección de implementación para ejecutarla en etiquetas:
En .travis.yml localice:
on :
repo : repo/repo Y agregue tags: true y skip_cleanup: true :
skip_cleanup : true
on :
repo : repo/repo
tags : trueEso le permitirá a Travis saber cómo crear una implementación cuando se inserte una nueva etiqueta y evitará que Travis limpie el archivo zip generado.
Si incorpora muchos marcos dinámicos en su aplicación, sus tiempos previos al inicio principal pueden ser bastante lentos. Carthage puede ayudar a mitigar esto construyendo sus marcos dinámicos como marcos estáticos. Los marcos estáticos se pueden vincular directamente a su aplicación o fusionarse en un marco dinámico más grande con algunas modificaciones simples en su flujo de trabajo, lo que puede resultar en reducciones dramáticas en los tiempos previos al lanzamiento principal.
Desde la versión 0.30.0, el proyecto Carthage implementa soporte para marcos vinculados estáticamente escritos en Swift u Objective-C, cuyo soporte se introdujo en Xcode 9.4. Sin embargo, tenga en cuenta que dice específicamente frameworks , por lo que Darwin incluye la extensión .framework y archivos de objetos vinculados estáticamente en su interior. Carthage no admite actualmente esquemas de bibliotecas estáticas, ni hay planes para introducir su soporte en el futuro.
El flujo de trabajo apenas difiere:
Sin embargo:
Consulte el documento StaticFrameworks para obtener más detalles.
Tenga en cuenta que se aplican algunas advertencias a este enfoque:
¿Quieres anunciar que tu proyecto se puede utilizar con Cartago? Puedes agregar una insignia de compatibilidad:
… a tu README , simplemente insertando el siguiente Markdown:
[ ![ Carthage compatible ] ( https://img.shields.io/badge/Carthage-compatible-4BC51D.svg?style=flat )] ( https://github.com/Carthage/Carthage ) El marco prediseñado no se puede depurar mediante la ejecución por pasos en otra máquina que no sea en la que se creó el marco. Simplemente carthage bootstrap/build/update --no-use-binaries debería solucionar este problema, pero para obtener una solución alternativa más automatizada, consulte el n.º 924. Dupe rdar://23551273 si desea que Apple solucione la causa raíz de este problema.
La mayor parte de la funcionalidad de la herramienta de línea de comandos carthage está encapsulada en un marco llamado CarthageKit.
Si está interesado en utilizar Carthage como parte de otra herramienta, o quizás en ampliar la funcionalidad de Carthage, eche un vistazo al código fuente de CarthageKit para ver si la API se ajusta a sus necesidades.
CocoaPods es un administrador de dependencias de larga data para Cocoa. Entonces, ¿por qué se creó Cartago?
En primer lugar, CocoaPods (de forma predeterminada) crea y actualiza automáticamente un espacio de trabajo de Xcode para su aplicación y todas las dependencias. Carthage construye binarios de framework usando xcodebuild , pero deja la responsabilidad de integrarlos al usuario. El enfoque de CocoaPods es más fácil de usar, mientras que el de Carthage es flexible y discreto.
El objetivo de CocoaPods figura en su archivo README de la siguiente manera:
… para mejorar la capacidad de descubrimiento y la participación en bibliotecas de código abierto de terceros, mediante la creación de un ecosistema más centralizado.
Por el contrario, Carthage se creó como un administrador de dependencia descentralizado . No existe una lista central de proyectos, lo que reduce el trabajo de mantenimiento y evita cualquier punto central de falla. Sin embargo, el descubrimiento de proyectos es más difícil: los usuarios deben recurrir a las páginas de tendencias de GitHub o similares.
Los proyectos CocoaPods también deben tener lo que se conoce como un archivo podspec, que incluye metadatos sobre el proyecto y especifica cómo se debe construir. Carthage usa xcodebuild para crear dependencias; en lugar de integrarlas en un único espacio de trabajo, no tiene un archivo de especificación similar, pero sus dependencias deben incluir su propio proyecto Xcode que describa cómo construir sus productos.
En última instancia, creamos Carthage porque queríamos la herramienta más simple posible: un administrador de dependencias que hiciera el trabajo sin asumir la responsabilidad de Xcode y sin crear trabajo adicional para los autores del marco. CocoaPods ofrece muchas funciones sorprendentes que Carthage nunca tendrá, a expensas de una complejidad adicional.
Carthage se publica bajo la licencia MIT.
La foto de fondo del encabezado se publica bajo la licencia CC BY-NC-SA 2.0. Foto original de Richard Mortel.
