Construyendo una biblioteca estática con cocoapods

Estoy intentando crear una biblioteca estática que tenga diferentes dependencies (AFNetworking por ejemplo) especificadas en un Podfile. No quiero que las dependencies se incluyan en la biblioteca estática final (llama a libMyProject.a), solo quiero vincularlas y luego crear un file MyProject.Podspec donde puedo poner las mismas dependencies.

El problema es que cuando compilo libMyProject.a, libPods.a está vinculado e incluido, de modo que si distribuyo libMyProject.a y otras personas lo integran en un proyecto que utiliza algunas de las mismas dependencies, tendrá problemas de símbolos duplicates.

¿Cómo puedo enlazar con libPods.a lib pero no includelo en libMyProject.a? Debería funcionar igual que enlazar con otros frameworks existentes.

¡Gracias!

Lo solucioné eliminando libPods.a lib de la sección "Vincular binary con bibliotecas" en Fases de compilation.

Aunque la eliminación manual de libPods.a de la fase de compilation "Enlace binary con bibliotecas" funciona, la respuesta real es no permitir que se agregue allí en primer lugar.

La razón por la que se agrega es porque el command de installation de pod está encontrando el objective de la biblioteca estática como uno de sus objectives para vincular. Esto podría deberse a que es el primer objective en la list (la implementación de los cocoapods hace que escoja el primero si no ha especificado explícitamente los objectives) o podría ser porque lo ha indicado explícitamente en la sección 'link_with'.

La respuesta que encuentro es usar la sección link_with del Podfile para indicar explícitamente sus objectives y omitir el objective de la biblioteca estática .

El proyecto de pods todavía se crea y sus dependencies se colocan allí como cabría esperar, pero el libPods.a no se agrega a la fase de compilation de su biblioteca estática.

El único problema es qué poner en la sección link_with, si no su biblioteca estática. Si tiene otros objectives con los que desea vincular (un objective de aplicación de iPhone, por ejemplo), esa es una buena opción. Pero si su único objective real es su biblioteca estática, necesita una pequeña solución.

Mi estrategia exitosa hasta el momento ha sido crear un objective de biblioteca estático (sí, uno separado de su biblioteca estática principal ) y llamarlo "Ficticio". Especifique este objective en la sección link_with de su Podfile.

Es un poco desagradable, concedido, pero funciona.

platform :ios, '5.1.1' link_with ['Dummy'] pod 'AFNetworking', '= 1.3.1' 

Las bibliotecas referencedas no están (de forma pnetworkingeterminada) incluidas en el producto de biblioteca estática. El conflicto del linker que está viendo es más probable que sea el resultado tanto de su biblioteca estática como de la aplicación del cliente, tanto con el objective pnetworkingeterminado (implícito) de Pod.

Cada objective generado por Cocoapods incluye un file "Pods- target -dummy.m" que se comstack en el producto; si usa el objective pnetworkingeterminado de Pods, se llama simplemente "Pods-dummy.m". Cuando tanto la biblioteca como el cliente utilizan el destino pnetworkingeterminado, los símbolos idénticos producidos a partir de la compilation de los files ficticios causarán un error de enlace.

link_with una variación de la respuesta de Craig y descubrí que la instrucción link_with también es responsable de conectar el xcconfig generado por Cocoapods, que proporciona las banderas del comstackdor que controlan la ruta de búsqueda del encabezado. Puede agregar manualmente el xcconfig (o la configuration del proyecto de la ruta de búsqueda del encabezado), por supuesto, pero busqué una solución repetible para mi equipo.

Mi solución es crear un objective explícito para la biblioteca, con un nombre que es poco probable que cause conflictos con un proyecto de cliente (por ejemplo, el nombre de la biblioteca):

 target 'XYZLibrary' do pod 'AFNetworking', '2.5.2' ... end 

Puede include una sentencia link_with dentro del bloque de target si el nombre del objective de la biblioteca estática (en su proyecto Xcode) es diferente, pero si solo hay un objective, generalmente prefiero usar el mismo nombre en ambos lugares, lo que hace que link_with unnecessary.

Si tiene un objective de testing de unidad, cree dos objectives separados. ( def actualmente un set de modules comunes que se utilizan en ambos objectives, ya que los objectives abstractos no son actualmente una opción, pero pueden ser de un día). Se ve así:

 def common_pods pod 'AFNetworking', '2.5.2' end target 'XYZLibrary' do common_pods end target 'XYZLibraryTests' do common_pods end 

La key es no tener ningún elemento pod en la raíz del Podfile, por lo que Cocoapods no generará un destino pnetworkingeterminado. De esta manera, cada producto obtiene un único "Pods- target -dummy.m", y no hay conflicto cuando esos files de objects están vinculados entre sí.